Evidencia de auditoría en la nube para ISO 27001, NIS2 y DORA
María, Directora de Seguridad de la Información (CISO) en una empresa de analítica financiera en rápido crecimiento, tenía seis semanas antes de que confluyeran tres plazos. Su auditoría de seguimiento de ISO 27001:2022 ya estaba programada. NIS2 había situado a la empresa, como entidad importante, en un nuevo nivel de responsabilidad proactiva de la dirección. DORA estaba a punto de verificar si sus operaciones fintech podían demostrar resiliencia operativa digital. Al mismo tiempo, un gran cliente empresarial mantenía en suspenso un contrato hasta que su equipo superara una revisión detallada de aseguramiento de seguridad.
La empresa no era insegura. Ejecutaba cargas de trabajo de producción en AWS y Azure, utilizaba Microsoft 365 y varias plataformas SaaS críticas, aplicaba MFA, realizaba copias de seguridad de los datos, escaneaba vulnerabilidades y recopilaba registros en la nube. El problema era la prueba.
La evidencia estaba dispersa entre capturas de pantalla de Slack, páginas wiki de desarrollo, exportaciones de consolas en la nube, carpetas de compras, contratos jurídicos y garantías verbales de propietarios de plataformas. Cuando un auditor preguntaba: «Muéstreme cómo controla su entorno en la nube», un enlace a la página de cumplimiento de un proveedor de servicios en la nube no era suficiente. Los certificados del proveedor demostraban los controles del proveedor. No demostraban la parte de María en el modelo de responsabilidad compartida.
Ahí es donde fallan muchos programas de evidencia de auditoría de seguridad en la nube. No porque falten controles, sino porque la organización no puede demostrar, de forma estructurada y trazable, qué responsabilidades corresponden al proveedor, cuáles corresponden al cliente, cómo están configurados los controles de SaaS e IaaS, cómo se aplican los compromisos de los proveedores y cómo se conserva la evidencia para auditores, reguladores y clientes.
El cumplimiento en la nube ya no es un anexo técnico. Para un proveedor SaaS sujeto a NIS2, una entidad financiera sujeta a DORA o cualquier organización ISO 27001:2022 que utilice IaaS, PaaS y SaaS, la gobernanza de la nube forma parte del alcance del SGSI, del plan de tratamiento de riesgos, del ciclo de vida de proveedores, del proceso de incidentes, de la responsabilidad proactiva en materia de privacidad y de la revisión por la dirección.
El objetivo práctico es sencillo: construir una arquitectura única de evidencia en la nube, apta para reguladores, que responda a preguntas de ISO 27001:2022, NIS2, DORA, GDPR, aseguramiento de clientes y auditoría interna sin reconstruir evidencia para cada marco.
La nube siempre está dentro del alcance, incluso cuando la infraestructura está externalizada
La primera trampa de auditoría consiste en asumir que la infraestructura externalizada queda fuera del SGSI. No es así. La externalización cambia el perímetro de control, pero no elimina la responsabilidad proactiva.
ISO/IEC 27001:2022 exige que la organización defina su contexto, las partes interesadas, el alcance del SGSI, las interfaces, las dependencias y los procesos. En una organización que prioriza la nube, el proveedor de identidad, la cuenta de alojamiento en la nube, el CRM, la plataforma de correo electrónico, el almacén de datos, la canalización de CI/CD, la herramienta de tickets y el servicio de copia de seguridad suelen ser infraestructura esencial de la organización.
Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec Zenith Blueprint subraya este punto en la fase de fundamentos y liderazgo del SGSI, paso 2, necesidades de las partes interesadas y alcance del SGSI:
«Si externaliza su infraestructura de TI a un proveedor de servicios en la nube, eso no la excluye del alcance; al contrario, debe incluir la gestión de esa relación y los activos en la nube como parte del alcance, porque la seguridad de sus datos en la nube sigue siendo su responsabilidad».
Esa afirmación es un ancla de auditoría. Su alcance no debería decir: «AWS está excluido porque lo gestiona Amazon». Debería indicar que los activos de información y los procesos relacionados con servicios alojados en AWS están dentro del alcance, incluida la gestión de controles de seguridad en la nube, identidad, registro de eventos, cifrado, copias de seguridad, aseguramiento de proveedores y respuesta a incidentes.
Para ISO 27001:2022, esto respalda las cláusulas 4.1 a 4.4 sobre contexto, partes interesadas, alcance y procesos del SGSI. Para NIS2, respalda las expectativas de Article 21 sobre análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y mantenimiento seguros, control de acceso, gestión de activos, criptografía, eficacia del control y MFA cuando proceda. Para DORA, respalda el principio de que las entidades financieras siguen siendo responsables del riesgo de las TIC incluso cuando los servicios de TIC están externalizados.
La pregunta no es si su proveedor de servicios en la nube es seguro. La pregunta es si usted gobierna su uso del proveedor, configura correctamente su parte, supervisa el servicio, gestiona los compromisos del proveedor y conserva evidencia.
La responsabilidad compartida debe convertirse en evidencia compartida
Los proveedores de servicios en la nube explican la responsabilidad compartida. Los auditores comprueban si usted la ha llevado a la práctica.
En IaaS, el proveedor suele proteger las instalaciones físicas, la infraestructura central y el hipervisor. El cliente controla la identidad, la configuración de las cargas de trabajo, el bastionado del sistema operativo, la seguridad de las aplicaciones, la clasificación de datos, los ajustes de cifrado, las reglas de red, el registro de eventos, las copias de seguridad, la aplicación de parches y la respuesta a incidentes.
En SaaS, el proveedor controla la mayor parte de las operaciones de la plataforma, pero el cliente sigue controlando la configuración del tenant, los usuarios, los roles administrativos, las integraciones, el uso compartido de datos, la conservación, las opciones de registro y los procedimientos de escalado.
Zenith Controls: guía de cumplimiento cruzado de Clarysec Zenith Controls trata el control 5.23 de ISO/IEC 27002:2022, seguridad de la información para el uso de servicios en la nube, como un control central de gobernanza de la nube con finalidad preventiva sobre la confidencialidad, integridad y disponibilidad. Vincula los servicios en la nube con las relaciones con proveedores, la transferencia segura de información, el inventario de activos, la prevención de fuga de datos, la seguridad de endpoints y redes, y las prácticas de desarrollo seguro.
Una interpretación clave de Zenith Controls indica:
«Los proveedores de servicios en la nube (CSP) funcionan como proveedores críticos y, por tanto, se aplican todos los controles relativos a selección de proveedores, contratación y gestión de riesgos bajo 5.19. Sin embargo, 5.23 va más allá al abordar riesgos específicos de la nube, como la multitenencia, la transparencia de la ubicación de los datos y los modelos de responsabilidad compartida».
Esa distinción es crítica. Los certificados del proveedor por sí solos no satisfacen el Anexo A.5.23. Se necesita evidencia del lado del cliente que demuestre que el servicio en la nube se gobierna, configura, supervisa y revisa.
| Área de evidencia | Qué quiere ver el auditor | Prueba típica |
|---|---|---|
| Inventario de la nube | Se conocen los servicios SaaS, PaaS e IaaS aprobados | Registro de servicios en la nube, lista de propietarios, tipos de datos, regiones, contratos |
| Responsabilidad compartida | Están documentadas las responsabilidades del proveedor y del cliente | Matriz de responsabilidades, documentación del proveedor, mapeo de controles internos |
| Configuración de referencia | Los ajustes controlados por el cliente siguen una referencia aprobada | Informes de CSPM, exportaciones de puntuación segura, comprobaciones de políticas de Terraform, capturas de pantalla |
| Identidad y acceso | El acceso administrativo y de usuario está controlado y revisado | Informes de MFA, configuración de SSO, revisión de roles privilegiados, muestras de baja |
| Registro y supervisión | Los registros relevantes de la nube están habilitados, conservados y revisados | Integración con SIEM, reglas de alerta, configuración de conservación de registros, tickets de incidentes |
| Compromisos del proveedor | Los contratos contienen cláusulas de seguridad exigibles | Contrato de encargo de tratamiento, SLA, derechos de auditoría, notificación de brecha de seguridad, términos de subcontratistas |
| Continuidad y salida | Los servicios críticos pueden recuperarse o transferirse | Pruebas de copias de seguridad, plan de salida, evidencia de recuperación, revisión del riesgo de concentración |
| Preparación ante incidentes | Los incidentes en la nube pueden detectarse, clasificarse y notificarse | Playbooks, evidencia de escalado, flujo de trabajo de notificación a reguladores |
Esta es la diferencia entre tener controles en la nube y tener controles en la nube preparados para auditoría.
Empiece con un registro de servicios en la nube que los auditores puedan utilizar
La forma más rápida de mejorar la preparación para auditorías en la nube es crear un registro de servicios en la nube completo. No debe ser una lista de compras ni una exportación financiera. Debe conectar los servicios en la nube con datos, propietarios, regiones, accesos, contratos, criticidad, relevancia regulatoria y evidencia.
La Política de Uso de la Nube para pymes de Clarysec Política de Uso de la Nube para pymes ofrece una base compacta y adecuada para auditoría en la cláusula 5.3:
«El proveedor externo de TI o el Director General deben mantener un registro de servicios en la nube. Debe registrar: 5.3.1 El nombre y la finalidad de cada servicio en la nube aprobado 5.3.2 La persona o el equipo responsable (propietario de la aplicación) 5.3.3 Los tipos de datos almacenados o tratados 5.3.4 El país o la región donde se almacenan los datos 5.3.5 Los permisos de acceso de usuarios y las cuentas administrativas 5.3.6 Los datos contractuales, fechas de renovación y contactos de soporte»
Para entornos empresariales, la Política de Uso de la Nube de Clarysec Política de Uso de la Nube establece el mandato más amplio:
«Esta política establece los requisitos obligatorios de la organización para el uso seguro, conforme y responsable de servicios de computación en la nube en los modelos de prestación infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como servicio (SaaS)».
La Política de Uso de la Nube exige un registro centralizado propiedad del Director de Seguridad de la Información y configuraciones de referencia aprobadas para los entornos en la nube. Ese registro se convierte en la base probatoria de varias obligaciones a la vez.
Para ISO 27001:2022, respalda el inventario de activos, la gobernanza del uso de la nube, las relaciones con proveedores, el control de acceso, los requisitos legales y contractuales, el tratamiento de riesgos y la información documentada. Para NIS2, respalda la seguridad de la cadena de suministro, la gestión de activos, el análisis de riesgos, la gestión de incidentes y la continuidad. Para DORA, respalda el mapeo de activos y dependencias de TIC, los registros de terceros de TIC, el mapeo de funciones críticas o importantes y el análisis del riesgo de concentración. Para GDPR, identifica si se tratan datos personales, dónde se ubican, qué proveedor actúa como encargado del tratamiento y qué términos de transferencia o tratamiento de datos se aplican.
Si el registro no identifica categorías de datos y regiones, la evidencia de privacidad y resiliencia estará incompleta. Si no identifica propietarios de aplicaciones, las revisiones de acceso quedarán huérfanas. Si no identifica contratos y fechas de renovación, las cláusulas de seguridad de proveedores no podrán probarse.
Convierta ISO 27001:2022 en la columna vertebral de la evidencia en la nube
ISO 27001:2022 es la mejor columna vertebral para la evidencia en la nube porque conecta contexto de negocio, riesgo, controles, pruebas operativas, supervisión y mejora.
Entre los requisitos de ISO 27001:2022 más relevantes para la nube se incluyen:
- Cláusulas 4.1 a 4.4 sobre contexto, partes interesadas, alcance del SGSI, interfaces, dependencias y procesos.
- Cláusulas 5.1 a 5.3 sobre liderazgo, política, roles, responsabilidades y responsabilidad proactiva.
- Cláusulas 6.1.1 a 6.1.3 sobre evaluación de riesgos, tratamiento de riesgos, comparación con el Anexo A, Declaración de aplicabilidad y aceptación del riesgo residual.
- Cláusula 7.5 sobre información documentada controlada.
- Cláusulas 8.1 a 8.3 sobre planificación operacional, ejecución de la evaluación de riesgos y ejecución del tratamiento de riesgos.
- Cláusulas 9.1 a 9.3 sobre supervisión, medición, auditoría interna y revisión por la dirección.
- Cláusula 10 sobre no conformidad, acción correctiva y mejora continua.
Los controles del Anexo A que soportan mayor carga de evidencia en la nube incluyen A.5.19 Seguridad de la información en las relaciones con proveedores, A.5.20 Tratamiento de la seguridad de la información en acuerdos con proveedores, A.5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, A.5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores, A.5.23 Seguridad de la información para el uso de servicios en la nube, A.5.24 a A.5.27 gestión de incidentes, A.5.29 Seguridad de la información durante interrupciones, A.5.30 Preparación de las TIC para la continuidad del negocio, A.5.31 Requisitos legales, estatutarios, reglamentarios y contractuales, A.5.34 Privacidad y protección de información de identificación personal (PII), A.5.36 Cumplimiento de políticas, reglas y estándares de seguridad de la información, A.8.8 Gestión de vulnerabilidades técnicas, A.8.9 gestión de configuraciones, A.8.13 Copia de seguridad de la información, A.8.15 registro de eventos, A.8.16 actividades de supervisión, A.8.24 Uso de criptografía, A.8.25 ciclo de vida de desarrollo seguro, A.8.29 pruebas de seguridad en desarrollo y aceptación, y A.8.32 Gestión de cambios.
En Zenith Blueprint, la fase de controles en acción, paso 23, explica los servicios en la nube con un lenguaje que encaja con la perspectiva de los auditores:
«El cambio hacia los servicios en la nube introduce transformaciones profundas en el modelo de confianza. Ya no controla el servidor, el perímetro de red ni el hipervisor. A menudo, ni siquiera sabe dónde residen físicamente los datos. Lo que sí controla, y lo que este control aplica, es la gobernanza de esa relación, la visibilidad sobre lo que utiliza y las expectativas de seguridad que impone a sus proveedores».
Una entrada sólida de la Declaración de aplicabilidad para A.5.23 no debería decir solo «Aplicable, proveedor de nube certificado». Debe explicar por qué aplica el control, qué riesgos trata, cómo se implementa y dónde se almacena la evidencia.
| Campo de la SoA | Ejemplo de contenido para A.5.23 |
|---|---|
| Aplicabilidad | Aplicable porque servicios críticos para las operaciones de la organización se ejecutan en plataformas SaaS e IaaS |
| Justificación | Los servicios en la nube tratan datos de clientes, datos de empleados y cargas de trabajo de producción |
| Riesgos tratados | Configuración incorrecta, acceso no autorizado, fuga de datos, fallo del proveedor, cambio de región, deficiencias de registro |
| Estado de implementación | Registro de la nube mantenido, configuraciones de referencia aprobadas, MFA aplicado, registros integrados, revisiones de proveedores realizadas |
| Evidencia | Registro de la nube, informes de configuración, revisión de acceso, paneles SIEM, contrato con proveedor, revisión de informe SOC, prueba de copia de seguridad |
| Mapeo regulatorio | NIS2 Article 21, DORA Articles 28 to 30, GDPR Articles 28 and 32, contratos con clientes |
| Propietario | Director de Seguridad de la Información para la gobernanza, Arquitecto de Seguridad de la Nube para la referencia, propietarios de aplicaciones para controles a nivel de servicio |
Añada una columna de ubicación de evidencia a la SoA o al seguimiento de controles. Los auditores no deberían tener que buscar en correo electrónico, sistemas de tickets y unidades compartidas para encontrar pruebas.
Utilice un único modelo de evidencia para ISO 27001:2022, NIS2 y DORA
NIS2 y DORA exigen ciberseguridad documentada, basada en riesgos y dirigida por la dirección. El solapamiento es considerable, pero la presión supervisora es diferente.
NIS2 se aplica a muchas entidades esenciales e importantes en la UE, incluidos proveedores de infraestructura digital, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, banca, infraestructuras de mercados financieros y proveedores digitales. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y mantenimiento seguros, gestión de vulnerabilidades, evaluación de la eficacia de los controles, higiene cibernética, formación, criptografía, control de acceso, gestión de activos y MFA o comunicaciones seguras cuando proceda.
Para la evidencia de auditoría de seguridad en la nube, NIS2 pregunta si los riesgos de nube y proveedores se gestionan como parte del riesgo de prestación del servicio. También introduce la notificación estructurada de incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, la notificación del incidente en un plazo de 72 horas y un informe final en un mes.
DORA se aplica desde el 17 de enero de 2025 a muchas entidades financieras de la UE y establece requisitos uniformes para la gestión del riesgo de las TIC, la notificación de incidentes graves de TIC, las pruebas de resiliencia operativa digital, el intercambio de información y el riesgo de terceros de TIC. Para las entidades financieras también identificadas bajo NIS2, DORA se trata como el acto jurídico sectorial específico de la Unión para las obligaciones operativas solapadas.
Para la nube, DORA es directo. Las entidades financieras siguen siendo responsables del riesgo de las TIC cuando los servicios están externalizados. Necesitan estrategias de terceros de TIC, registros contractuales, evaluaciones precontractuales, diligencia debida, derechos de auditoría y acceso, desencadenantes de terminación, análisis del riesgo de concentración, controles de subcontratación y estrategias de salida probadas.
Zenith Controls mapea el control 5.23 de ISO/IEC 27002:2022 con EU NIS2 Article 21 y DORA Articles 28 to 31. También señala estándares de apoyo como ISO/IEC 27017 para roles de seguridad en la nube y supervisión, ISO/IEC 27018 para la protección de PII en nube pública, ISO/IEC 27701 para la gestión de la privacidad en relaciones con encargados del tratamiento en la nube, ISO/IEC 27036-4 para supervisión de servicios en la nube y acuerdos con proveedores, e ISO/IEC 27005 para evaluación de riesgos en la nube.
| Marco | Cláusula o artículo relevante | Cómo ayuda la evidencia de A.5.23 |
|---|---|---|
| ISO 27001:2022 | Cláusulas 4, 6, 8, 9 y Anexo A.5.23 | Demuestra que el uso de la nube está dentro del alcance, evaluado en riesgos, controlado, supervisado, auditado y mejorado |
| NIS2 | Article 21 | Demuestra medidas proporcionadas para seguridad de la cadena de suministro, control de acceso, continuidad, gestión de incidentes y gestión de activos |
| DORA | Articles 28 to 31 | Respalda la diligencia debida de terceros de TIC, contratos, supervisión, riesgo de concentración, planes de salida y vigilancia |
| GDPR | Articles 28 and 32 | Respalda la gobernanza de encargados del tratamiento, la seguridad del tratamiento, la preparación ante brechas de seguridad y la responsabilidad proactiva de privacidad en la nube |
La implicación práctica es sencilla. No construya paquetes de evidencia separados para ISO 27001:2022, NIS2, DORA y GDPR. Construya una única arquitectura de evidencia en la nube con mapeos específicos por marco.
Los contratos con proveedores son evidencia de control, no archivos jurídicos
La evidencia de auditoría en la nube suele fallar en la capa contractual. Seguridad tiene un cuestionario de proveedor. Legal tiene el contrato marco de servicios (MSA). Compras tiene la fecha de renovación. El DPO tiene el contrato de encargo de tratamiento. Nadie tiene una visión única de si el acuerdo incluye las cláusulas de seguridad exigidas por ISO 27001:2022, NIS2, DORA y GDPR.
La Política de Seguridad de Terceros y Proveedores para pymes de Clarysec Política de Seguridad de Terceros y Proveedores para pymes establece en la cláusula 5.3:
«Los contratos deben incluir cláusulas obligatorias que cubran: 5.3.1 Confidencialidad y no divulgación 5.3.2 Obligaciones de seguridad de la información 5.3.3 Plazos de notificación de brechas de seguridad de los datos (por ejemplo, dentro de 24–72 horas) 5.3.4 Derechos de auditoría o disponibilidad de evidencia de cumplimiento 5.3.5 Restricciones a subcontrataciones posteriores sin aprobación 5.3.6 Términos de terminación, incluida la devolución o destrucción segura de datos»
Para la coherencia de auditoría, convierta esas cláusulas en una matriz de revisión contractual. El Anexo A.5.20 de ISO 27001:2022 espera que los requisitos de seguridad se acuerden con los proveedores. GDPR Article 28 exige términos para encargados del tratamiento que cubran confidencialidad, medidas de seguridad, asistencia, subencargados, supresión o devolución de datos y soporte de auditoría. DORA Article 30 exige disposiciones contractuales detalladas para proveedores terceros de TIC, incluidas descripciones de servicios, ubicación de datos, seguridad, asistencia en incidentes, cooperación con autoridades, derechos de auditoría, derechos de acceso, terminación y acuerdos de transición. La seguridad de la cadena de suministro de NIS2 también requiere cooperación exigible de los proveedores.
Zenith Controls mapea el control 5.20 de ISO/IEC 27002:2022 con acuerdos con proveedores y señala vínculos con 5.19 relaciones con proveedores, 5.14 transferencia de información, 5.22 supervisión de proveedores, 5.11 devolución de activos y 5.36 cumplimiento.
El punto clave es la puesta en práctica. Si un contrato de nube concede acceso a informes SOC 2, los auditores pueden preguntar si obtuvo el informe, revisó las excepciones, hizo seguimiento de la remediación y reevaluó el riesgo. Si el contrato promete notificación de brechas de seguridad, pueden preguntar si su playbook de incidentes incluye la vía de contacto con el proveedor y los puntos de decisión regulatorios. Si los cambios de subcontratistas requieren aprobación o notificación, pueden preguntar si las notificaciones de subencargados se revisan antes de aceptarlas.
Un contrato sin evidencia de revisión es un archivo. Un contrato vinculado a riesgo de proveedores, registros de supervisión y flujos de trabajo de incidentes es un control.
El registro y la configuración de SaaS son puntos ciegos habituales en auditoría
Los hallazgos en la nube suelen venir de SaaS, no de IaaS. Los equipos de infraestructura suelen tener propietarios de ingeniería, canalizaciones de registro, controles de referencia y registros de cambios. Las plataformas SaaS están fragmentadas entre ventas, Recursos Humanos, finanzas, éxito del cliente, marketing y operaciones. Cada una puede tratar datos sensibles o regulados.
La Política de registro y supervisión para pymes de Clarysec Política de registro y supervisión para pymes aborda esto directamente en la cláusula 5.5:
«5.5 Servicios en la nube y registro de terceros 5.5.1 Para plataformas donde el registro de eventos no está bajo control directo de TI (por ejemplo, correo electrónico SaaS), se aplican los siguientes requisitos: 5.5.1.1 El registro debe estar habilitado y configurado cuando esté disponible 5.5.1.2 Las alertas deben enrutarse al proveedor de soporte de TI 5.5.1.3 Los contratos deben exigir que los proveedores conserven registros durante al menos 12 meses y proporcionen acceso previa solicitud»
Para empresas, la Política de Uso de la Nube añade:
«Los servicios en la nube deben integrarse en el SIEM de la organización para una supervisión continua».
Este requisito traslada SaaS de «herramienta de negocio» a «sistema de información supervisado». La evidencia debe incluir exportaciones de configuración de registro, prueba del conector SIEM, reglas de alerta, tickets de triaje, configuración de conservación y revisiones de acceso administrativo.
Para SaaS crítico, prepare evidencia de creación de cuentas administrativas, inicios de sesión sospechosos, descargas masivas, uso compartido público, deshabilitación de MFA, creación de tokens de API, actividad de invitados externos y elevaciones de privilegios. Para IaaS, prepare CloudTrail o registro equivalente del plano de control, registros de acceso al almacenamiento, cambios de IAM, registros de flujo cuando proceda, hallazgos de CSPM, escaneos de vulnerabilidades, evidencia de parches, configuración de cifrado, estado de copias de seguridad, revisiones de grupos de seguridad de red y tickets de cambio.
La metodología de auditoría de Zenith Controls para el control 5.23 señala que una auditoría estilo ISO/IEC 27007 puede inspeccionar permisos de buckets AWS S3, cifrado, políticas IAM y registro de CloudTrail. Un auditor orientado a COBIT puede revisar configuraciones de alerta, controles DLP, uso de Microsoft 365 Secure Score y registros de gestión de cambios. Una perspectiva NIST SP 800-53A puede probar la gestión de cuentas y la supervisión, incluido si las cargas de trabajo en la nube se parchean, escanean y supervisan con el mismo rigor que los sistemas internos.
Distintos auditores hablan distintos dialectos. Su evidencia debe ser la misma.
Construya un paquete de evidencia apto para reguladores para un servicio SaaS y un servicio IaaS
Un flujo de trabajo práctico empieza con una plataforma SaaS crítica y un entorno IaaS crítico. Por ejemplo, Microsoft 365 para colaboración y AWS para alojamiento de producción.
Paso 1: Actualice el registro de servicios en la nube
Para Microsoft 365, registre finalidad, propietario, tipos de datos, región, cuentas administrativas, contrato, contrato de encargo de tratamiento, contacto de soporte, fecha de renovación y criticidad. Para AWS, registre la cuenta de producción, regiones, categorías de datos, cargas de trabajo, propietario de la cuenta, estado de la cuenta root, plan de soporte, términos contractuales y servicios de negocio vinculados.
Use los campos de la Política de Uso de la Nube para pymes como conjunto mínimo de datos. Añada criticidad, relevancia regulatoria y ubicación de la evidencia.
Paso 2: Documente la responsabilidad compartida
Para Microsoft 365, las responsabilidades del cliente incluyen el ciclo de vida de usuarios, MFA, acceso condicional, uso compartido con invitados, etiquetas de conservación, DLP cuando se utilice, registro de eventos y escalado de incidentes. Para AWS, las responsabilidades del cliente incluyen IAM, reglas de red, bastionado de cargas de trabajo, configuración de cifrado, copia de seguridad, registro de eventos, aplicación de parches y seguridad de aplicaciones.
Adjunte la documentación de responsabilidad compartida del proveedor y, después, mapee cada responsabilidad del cliente con un propietario de control y una fuente de evidencia.
Paso 3: Capture evidencia de configuración
Para Microsoft 365, exporte o capture políticas de MFA y acceso condicional, roles administrativos, configuración de uso compartido externo, registro de auditoría, configuración de conservación y acciones de puntuación de seguridad. Para AWS, exporte la política de contraseñas IAM, el estado de MFA privilegiado, la configuración de CloudTrail, el bloqueo de acceso público de S3, el estado de cifrado, la revisión de grupos de seguridad, trabajos de copia de seguridad y estado de escaneos de vulnerabilidades.
La Política de Uso de la Nube exige que los entornos en la nube cumplan una configuración de referencia documentada y aprobada por el Arquitecto de Seguridad de la Nube. Su paquete de evidencia debe incluir tanto la referencia como la prueba de alineación.
| Requisito de la política | Acción realizada | Evidencia de auditoría generada |
|---|---|---|
| MFA para acceso privilegiado | MFA aplicado en cuentas administrativas y acceso a consola | Exportación de política MFA, muestra de cuenta privilegiada, revisión de cuenta de emergencia |
| Registro de actividad | Registros de auditoría en la nube habilitados y enrutados al SIEM | Captura de CloudTrail o registro de auditoría SaaS, prueba de ingesta en SIEM, configuración de conservación |
| Restricciones de acceso | Roles de mínimo privilegio aplicados y revisiones de acceso trimestrales | Exportación de roles IAM, revisión de roles administrativos, aprobación formal del propietario de la información |
| Configuración segura | Ajustes de la nube medidos frente a la referencia aprobada | Informe CSPM, exportación de puntuación segura, registro de excepciones |
| Copia de seguridad y recuperación | Restauración probada para cargas de trabajo o datos críticos | Estado del trabajo de copia de seguridad, registro de prueba de restauración, lecciones aprendidas |
Paso 4: Vincule evidencia de proveedores y privacidad
Adjunte el contrato, el contrato de encargo de tratamiento, la lista de subencargados, los términos de notificación de brechas de seguridad, los informes de aseguramiento de auditoría y la evidencia de ubicación de datos. Si se tratan datos personales, registre si el proveedor actúa como encargado del tratamiento, cómo se gestiona la supresión, cómo funciona el soporte a solicitudes de los interesados y qué salvaguardas de transferencia se aplican.
Para DORA, identifique si el servicio en la nube soporta una función crítica o importante. En caso afirmativo, vincule la evidencia al registro de terceros de TIC, al expediente de diligencia debida, a los derechos de auditoría, al plan de salida y a la revisión del riesgo de concentración.
Paso 5: Conecte el registro de eventos con la respuesta a incidentes
Demuestre que los registros están habilitados, enrutados, revisados y utilizados. Adjunte paneles SIEM, reglas de alerta y al menos un ticket de alerta cerrado. Después, mapee el flujo de trabajo con los puntos de decisión de notificación de NIS2 y DORA.
Para NIS2, el proceso de incidentes debe soportar alerta temprana en 24 horas, notificación del incidente en 72 horas y un informe final en un mes para incidentes significativos. Para DORA, el proceso de incidentes de TIC debe clasificar los incidentes por clientes afectados, transacciones, duración, indisponibilidad, dispersión geográfica, impacto en los datos, criticidad del servicio e impacto económico.
Paso 6: Almacene la evidencia con disciplina
La Política de Auditoría y Supervisión del Cumplimiento para pymes de Clarysec Política de Auditoría y Supervisión del Cumplimiento para pymes, cláusula 6.2, define una disciplina práctica de evidencia:
«6.2 Recopilación y documentación de evidencia 6.2.1 Toda la evidencia debe almacenarse en una carpeta de auditoría centralizada. 6.2.2 Los nombres de archivo deben referenciar claramente el tema de auditoría y la fecha. 6.2.3 Los metadatos (por ejemplo, quién los recopiló, cuándo y desde qué sistema) deben documentarse. 6.2.4 La evidencia debe conservarse durante al menos dos años, o más cuando lo exijan la certificación o los acuerdos con clientes».
La Política de Auditoría y Supervisión del Cumplimiento empresarial Política de Auditoría y Supervisión del Cumplimiento establece el objetivo:
«Generar evidencia defendible y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos judiciales o solicitudes de aseguramiento de clientes».
Una captura llamada «screenshot1.png» es una evidencia débil. Un archivo denominado «AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png» es más sólido porque describe el sistema, el control, la fecha y la persona recopiladora. Los metadatos importan porque los auditores necesitan confiar en cuándo se recopiló la evidencia, quién la recopiló y desde qué sistema.
Cómo prueban los auditores el mismo control de nube
Los paquetes de evidencia en la nube más sólidos están diseñados para múltiples lentes de auditoría. Los auditores de ISO 27001:2022 comprueban si el control está en el SGSI, la evaluación de riesgos, el tratamiento de riesgos y la SoA. Los evaluadores orientados a NIST prueban la implementación técnica. Los auditores de COBIT 2019 prueban la gobernanza, el desempeño de proveedores y la integración de procesos. Los auditores de privacidad se centran en obligaciones de encargados del tratamiento, residencia de los datos, preparación ante brechas de seguridad y derechos de los interesados. Las revisiones supervisoras de DORA se centran en el riesgo de terceros de TIC y la resiliencia.
| Lente de auditoría | Pregunta probable de auditoría | Evidencia a preparar |
|---|---|---|
| ISO 27001:2022 | ¿Por qué es aplicable el control de nube y cómo se implementa bajo el SGSI? | Declaración de alcance, registro de riesgos, SoA, política de nube, registro, referencia, registros de auditoría interna |
| Auditoría de SGSI estilo ISO/IEC 27007 | ¿Puede validarse la configuración y la documentación mediante entrevistas y muestras? | Capturas de pantalla, exportaciones, validación de solo lectura, entrevistas con propietarios de nube y SaaS |
| NIST SP 800-53A | ¿Las cuentas en la nube, la supervisión y los servicios externos se controlan como los sistemas internos? | Revisión IAM, registros del ciclo de vida de cuentas, registros SIEM, escaneos de vulnerabilidades, requisitos de servicios externos |
| COBIT 2019 | ¿Los servicios de proveedores se supervisan, modifican y gobiernan según el riesgo de negocio? | Actas de revisión de proveedores, KPI, KRI, informes SLA, registros de cambios, reevaluaciones de riesgos |
| ISACA ITAF | ¿La evidencia es suficiente, fiable y se conserva para respaldar conclusiones? | Carpeta centralizada de evidencia, metadatos, exportaciones de origen, pistas de tickets, aprobaciones |
| Auditoría de privacidad y GDPR | ¿Las obligaciones de encargados del tratamiento y los controles de datos personales operan en la nube? | Contrato de encargo de tratamiento, CCT cuando proceda, prueba de residencia de los datos, proceso de supresión, acceso al registro de brechas de seguridad, pruebas de restauración |
| Revisión supervisora DORA | ¿Puede la entidad financiera demostrar supervisión y resiliencia de terceros de TIC? | Registro contractual de TIC, mapeo de funciones críticas, estrategia de salida, revisión del riesgo de concentración, resultados de pruebas |
| Requerimiento de autoridad competente NIS2 | ¿Puede la entidad mostrar medidas de ciberseguridad proporcionadas y preparación para la notificación de incidentes? | Mapeo de Article 21, playbook de incidentes, evidencia de seguridad de proveedores, pruebas de continuidad, aprobación de la dirección |
Zenith Controls incluye estas diferencias de metodología de auditoría para servicios en la nube, acuerdos con proveedores y supervisión de proveedores. Para 5.22, supervisión, revisión y gestión de cambios de servicios de proveedores, destaca que los auditores pueden inspeccionar actas trimestrales de revisión de proveedores, informes de KPI, evaluaciones de informes SOC, registro de cambios, evaluaciones de riesgos, incidentes de proveedores y seguimiento de incidencias. Para 5.20, tratamiento de la seguridad de la información en acuerdos con proveedores, destaca el muestreo contractual de confidencialidad, obligaciones de seguridad, notificación de brechas de seguridad, derechos de auditoría, aprobación de subcontratistas y términos de terminación.
Controles de cumplimiento cruzado que soportan la carga de auditoría en la nube
Un modelo de evidencia en la nube apto para reguladores se construye alrededor de un número reducido de controles de alto impacto. Estos controles soportan gran parte de la carga de cumplimiento en ISO 27001:2022, NIS2, DORA, GDPR, NIST y COBIT 2019.
| Tema de control | Ancla ISO 27001:2022 | Relevancia NIS2 | Relevancia DORA | Relevancia GDPR |
|---|---|---|---|---|
| Gobernanza de la nube | A.5.23 | Article 21 medidas de riesgo para nube y sistemas | Marco de riesgo de TIC y dependencias de terceros | Seguridad del tratamiento en la nube y supervisión de encargados |
| Acuerdos con proveedores | A.5.20 | Seguridad y cooperación en la cadena de suministro | Article 30 disposiciones contractuales | Article 28 contrato de encargado del tratamiento |
| Supervisión de proveedores | A.5.22 | Gestión continua del riesgo | Supervisión continua de terceros de TIC, KPI y KRI | Diligencia debida de encargados y revisión de seguridad |
| Registro y supervisión | A.8.15, A.8.16 | Detección de incidentes y eficacia del control | Detección, clasificación y notificación de incidentes de TIC | Detección de brechas de seguridad y responsabilidad proactiva |
| Control de acceso y MFA | A.5.15, A.5.16, A.5.17, A.5.18 | Control de acceso y MFA cuando proceda | Medidas de protección y prevención | Confidencialidad e integridad de datos personales |
| Copia de seguridad y resiliencia | A.8.13, A.5.29, A.5.30 | Continuidad del negocio y gestión de crisis | Continuidad, recuperación, copia de seguridad y restauración | Disponibilidad y resiliencia del tratamiento |
| Gestión de incidentes | A.5.24, A.5.25, A.5.26, A.5.27 | Flujo de notificación de 24 horas, 72 horas e informe final | Ciclo de vida de notificación inicial, intermedia y final | Evaluación de brechas de datos personales y notificación |
| Obligaciones legales y de privacidad | A.5.31, A.5.34 | Cumplimiento legal y normativo | Requisitos supervisores sectoriales | Tratamiento lícito, responsabilidad proactiva y contratos de Article 28 |
NIST SP 800-53 Rev.5 añade profundidad técnica mediante gestión de cuentas, servicios de sistemas externos, supervisión continua, supervisión de sistemas y protección de perímetro. COBIT 2019 añade profundidad de gobernanza mediante gestión de relaciones con proveedores, riesgo de proveedores, intercambio de datos, seguridad de redes y preparación para cambios.
Los estándares ISO de apoyo afinan el modelo de evidencia. ISO/IEC 27017 proporciona orientación específica de nube sobre roles compartidos, configuración de máquinas virtuales y supervisión de actividad del cliente. ISO/IEC 27018 se centra en la protección de PII en nube pública. ISO/IEC 27701 extiende las obligaciones de privacidad a las operaciones de encargados y responsables del tratamiento. ISO/IEC 27036-4 respalda los acuerdos con proveedores de nube y su supervisión. ISO/IEC 27005 respalda la evaluación de riesgos en la nube.
La revisión por la dirección debe ver el riesgo en la nube, no solo la disponibilidad de la nube
Uno de los artefactos de auditoría más ignorados es la revisión por la dirección. ISO 27001:2022 espera que la revisión por la dirección considere cambios, necesidades de partes interesadas, tendencias de desempeño, resultados de auditoría, estado del tratamiento de riesgos y oportunidades de mejora. NIS2 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad y supervisen su implementación. DORA exige que el órgano de dirección defina, apruebe, supervise y siga siendo responsable de la gestión del riesgo de las TIC.
Un panel trimestral de seguridad en la nube y proveedores debería mostrar:
- Número de servicios en la nube aprobados.
- Servicios en la nube críticos y propietarios.
- Servicios que tratan datos personales.
- Servicios que soportan funciones críticas o importantes.
- Configuraciones incorrectas de alto riesgo en la nube abiertas.
- Estado de revisión de MFA y acceso privilegiado.
- Cobertura de registro para plataformas SaaS e IaaS críticas.
- Informes de aseguramiento de proveedores recibidos y revisados.
- Excepciones contractuales y riesgos aceptados.
- Incidentes en la nube, cuasi incidentes y lecciones aprendidas.
- Resultados de pruebas de copia de seguridad y recuperación.
- Estado del riesgo de concentración y del plan de salida.
Este panel se convierte en evidencia para el liderazgo y la evaluación del desempeño de ISO 27001:2022, la gobernanza de NIS2 y la responsabilidad proactiva de la dirección bajo DORA.
Zenith Blueprint, en la fase de gestión de riesgos, paso 14, recomienda realizar referencias cruzadas con los requisitos regulatorios al implementar tratamientos de riesgos y políticas. Afirma que mapear requisitos clave de regulación con controles del SGSI es un ejercicio interno útil y «también impresiona a auditores/evaluadores porque demuestra que no se gestiona la seguridad en el vacío, sino con conocimiento del contexto legal».
Esa es la madurez que esperan los reguladores y los clientes empresariales.
Hallazgos comunes de auditoría en la nube y cómo evitarlos
En los trabajos de preparación para auditorías en la nube, los hallazgos recurrentes son previsibles:
- El registro de servicios en la nube existe, pero faltan herramientas SaaS.
- La ubicación de los datos no se registra o se copia de páginas de marketing en lugar de evidencia contractual.
- MFA se aplica a empleados, pero no a todas las cuentas administrativas o de emergencia.
- Los registros en la nube están habilitados, pero no se revisan, conservan ni conectan con la respuesta a incidentes.
- Los informes SOC de proveedores se archivan, pero no se evalúan.
- Existen cláusulas contractuales para nuevos proveedores, pero no para servicios críticos heredados.
- Las notificaciones de subencargados se reciben por correo electrónico, pero no se evalúan en términos de riesgo.
- Los trabajos de copia de seguridad se ejecutan correctamente, pero las pruebas de recuperación no se evidencian.
- Los ingenieros comprenden la responsabilidad compartida, pero no está documentada para auditores.
- La SoA marca controles de nube como aplicables, pero no los vincula con entradas de riesgo, evidencia o propietarios.
Estos son problemas de trazabilidad. La solución es conectar política, riesgo, control, propietario, evidencia y revisión.
Cuando María llegó al día de la auditoría, ya no dependía de capturas dispersas. Abrió un panel central que mostraba el registro de servicios en la nube, evaluaciones de riesgos, entradas de la SoA, evidencia de configuraciones de referencia, archivos de revisión de proveedores, pruebas de registro y la revisión del riesgo de concentración de DORA. Cuando el auditor preguntó cómo se gobernaban los riesgos en la nube, mostró el SGSI. Cuando el auditor preguntó cómo se configuraban los servicios de forma segura, mostró la referencia y la evidencia de CSPM. Cuando el auditor preguntó por el riesgo de terceros de TIC, mostró la revisión contractual, la supervisión de proveedores y la planificación de salida.
El resultado no fue un entorno perfecto. Ningún entorno en la nube lo es. La diferencia fue que las decisiones de riesgo estaban documentadas, la evidencia era defendible y la responsabilidad proactiva era visible.
Construya su paquete de evidencia en la nube antes de que lo pida el auditor
Si su organización depende de SaaS, IaaS o PaaS, su próxima auditoría no aceptará «lo gestiona el proveedor» como respuesta suficiente. Debe demostrar responsabilidad compartida, configuración del lado del cliente, cláusulas de proveedores, registro de eventos, preparación ante incidentes, resiliencia y supervisión de la dirección.
Empiece esta semana con tres acciones prácticas:
- Cree o actualice su registro de servicios en la nube usando la Política de Uso de la Nube de Clarysec Política de Uso de la Nube o la Política de Uso de la Nube para pymes Política de Uso de la Nube para pymes.
- Mapee sus cinco principales servicios en la nube con los controles del Anexo A de ISO 27001:2022, NIS2 Article 21, las obligaciones de terceros de TIC de DORA cuando apliquen y los requisitos de encargados del tratamiento de GDPR.
- Construya una carpeta centralizada de evidencia usando la disciplina de conservación y metadatos de la Política de Auditoría y Supervisión del Cumplimiento Política de Auditoría y Supervisión del Cumplimiento o la Política de Auditoría y Supervisión del Cumplimiento para pymes Política de Auditoría y Supervisión del Cumplimiento para pymes.
Después, use Zenith Blueprint Zenith Blueprint para situar el trabajo dentro de la hoja de ruta de auditoría del SGSI en 30 pasos, y Zenith Controls Zenith Controls para validar mapeos de cumplimiento cruzado, estándares ISO de apoyo y expectativas de metodología de auditoría.
Clarysec puede ayudarle a convertir capturas dispersas de la nube, archivos de proveedores y ajustes de SaaS en un paquete de evidencia apto para reguladores que resista auditorías de certificación ISO 27001:2022, preguntas supervisoras de NIS2, revisiones de terceros de TIC de DORA y exigencias de aseguramiento de clientes empresariales.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
