Servicios en la nube bajo ISO 27001: criterios de selección y controles para la integración en el SGSI

Muchas empresas enfrentan hoy la misma tensión: los servicios en la nube prometen velocidad y escalabilidad, el SGSI exige trazabilidad, operación controlada y responsabilidades claras. Precisamente aquí el tema central Servicios en la nube bajo ISO 27001 se vuelve relevante en la práctica. No porque la norma complique la „nube“ en sí, sino porque exige que identifique riesgos de forma sistemática, implemente controles de manera efectiva y documente todo de forma auditables. Suena a papeleo, pero en la nube se convierte rápidamente en preguntas operativas concretas: ¿Quién puede hacer qué? ¿Dónde residen los datos? ¿Cómo se registran los logs? ¿Cómo reaccionamos ante incidentes? ¿Y cómo salen si es necesario?

Este artículo ofrece una lógica sólida de selección e integración: criterios de decisión para la adquisición, controles concretos para la integración en el SGSI, perspectivas típicas de auditoría y recomendaciones de implementación desde la óptica de operación. El foco está en IaaS/PaaS/SaaS, es decir, servicios de infraestructura, plataforma y aplicaciones desde la nube —cada uno con consecuencias para la gobernanza, la administración y la seguridad.

Servicios en la nube bajo ISO 27001 en la práctica

En auditorías y revisiones internas aparecen patrones recurrentes que no dependen de configuraciones aisladas, sino de interfaces poco claras entre proveedor y cliente:

• Responsabilidades poco claras: el Modelo de Responsabilidad Compartida (Shared Responsibility Model) no se traduce en el día a día a tareas, roles y evidencias.
• Scope demasiado amplio: «Usamos la nube» no sustituye una delimitación del alcance. Sin un mapa de servicios, flujos de datos y dependencias, la gestión de riesgos es aleatoria.
• Selección de proveedor sin anexo de seguridad: compras y unidades funcionales priorizan capacidades; TI/Seguridad intervienen tarde. Resultado: SLA sin métricas de seguridad, ausencia de derechos de auditoría, subcontratistas poco claros.
• Falta de diseño de logging: existen logs, pero no están centralizados, no se correlacionan, no hay reglas de retención ni responsabilidades. En caso de incidente, entonces no se puede demostrar nada.
• Sin plan de salida: en la nube el lock-in rara vez es «solo precio». Son formatos de datos, acoplamientos de IAM, servicios propietarios y rutas de migración faltantes.

ISO 27001 no obliga a un control máximo, sino a un control adecuado y justificado. El paso decisivo es, por tanto, tratar los servicios en la nube como una relación con proveedores más una plataforma operativa crítica —con controles técnicos que puedan ser auditados.

Contextualización: ISO 27001, Anexo A y lo que la „nube“ cambia

ISO 27001 exige un sistema de gestión de la seguridad de la información (SGSI) con enfoque basado en riesgos, eficacia medible y mejora continua. El Anexo A (objetivos de control/controles, reorganizado en ISO/IEC 27001:2022) es una caja de herramientas, no un catálogo obligatorio de „todo siempre“. En la nube cambia la implementación:

• Los controles son más contractuales y procesales (p. ej., gestión de proveedores, evidencias de auditoría, transparencia sobre subcontratistas).
• Los controles son más orientados a la configuración (p. ej., IAM, cifrado, segmentación de red), porque usted controla menos a nivel físico.
• Las evidencias son más basadas en datos (p. ej., extractos de logs, exportaciones de configuración, registros de cambios), porque las listas de verificación clásicas de servidores ya no encajan.

En la práctica, es útil diferenciar por modelo de servicio: en SaaS usted controla sobre todo identidades, permisos, datos, integraciones y gestión de proveedores. En PaaS se añaden configuraciones de plataforma, controles de red y de tiempo de ejecución. En IaaS asume mucha más responsabilidad por los sistemas operativos, el hardening, la aplicación de parches y la arquitectura de red.

Criterios de selección: así evalúa los servicios en la nube antes de la compra

Desde la perspectiva del ISMS, la fase de selección es el momento más adecuado para incorporar seguridad y capacidad de auditoría. Más tarde, cualquier laguna resulta cara: adendas contractuales, soluciones alternativas, shadow IT o herramientas adicionales.

1) Ajuste del alcance y flujos de datos: ¿qué debe ir exactamente a la nube?

No empiece por las funcionalidades, sino por los valores informativos: ¿qué tipos de datos procesa el servicio (datos personales, confidenciales, críticos para la operación)? ¿Qué sistemas están conectados (ERP, IAM, correo electrónico, tickets)? Un servicio que exporta y distribuye datos necesita controles distintos a los de una herramienta aislada.

Evidencia mínima práctica: un ficha del servicio con propósito, categorías de datos, interfaces, grupos de usuarios, dependencias críticas y ventanas de operación. Esto será después el puente hacia la evaluación de riesgos, el Statement of Applicability (SoA) y las auditorías internas.

2) Traducir el Shared Responsibility Model a tareas concretas

Muchos proveedores documentan la responsabilidad compartida. Para su ISMS eso no es suficiente mientras no se traduzca en tareas concretas: ¿quién configura el MFA? ¿quién revisa los logs? ¿quién es responsable de las claves? ¿quién aplica parches (en IaaS)?

Ha demostrado ser efectiva una matriz RACI (Responsible, Accountable, Consulted, Informed) por área de control. Lo decisivo es “Accountable”: un rol interno que, en caso de duda, asume la responsabilidad ante auditores y la dirección.

3) Capacidad del proveedor: evidencias, derechos de auditoría, subcontratistas

ISO 27001 aborda explícitamente el control de proveedores. Para la nube esto significa: necesita información sólida sobre medidas de seguridad, subprocesadores/subcontratistas, cuestiones de ubicación/región y sobre las notificaciones en caso de incidentes de seguridad. Revise en particular:

• Estrategia de auditoría y evidencias: ¿recibe informes/evidencias adecuados (p. ej., informes de auditoría independientes) y son estos suficientes para su alcance?
• Transparencia sobre subcontratistas: ¿se nombran los subproveedores, se anuncian los cambios y existe derecho a oponerse?
• Vías y plazos de notificación: notificación de incidentes de seguridad (Security Incident Notification), puntos de contacto, contacto 24/7, contenidos mínimos de la notificación.
• Continuidad del servicio: disponibilidad, ventanas de mantenimiento, procesos de emergencia, backup/RESTore (en SaaS a menudo el punto crítico).

Si desea profundizar en los riesgos de los proveedores: planifique internamente un enlace a su artículo sobre gestión de proveedores (cláusulas contractuales, criterios técnicos de verificación, proceso de incorporación).

4) Capacidad de integración técnica: IAM, Logging, Netzwerk, Schlüssel

Un servicio en la nube no es «una herramienta», sino parte de su arquitectura de seguridad. Por ello, compruebe de antemano los puntos de integración:

• Integración IAM: SSO (Single Sign-On), SCIM (aprovisionamiento/desaprovisionamiento automatizado), modelo de roles, soporte para MFA y Conditional Access.
• Logging: exportación a su logging/SIEM central, detalles de logs (acciones de administrador, autenticación, accesos a datos), retención, consistencia de marcas de tiempo.
• Red y acceso: endpoints privados, RESTricciones de IP, separación de inquilinos, acceso a API, límites de tasa (Rate Limits).
• Cifrado/Gestión de claves: cifrado en reposo y en tránsito, claves del cliente (BYOK/CMK), rotación, opciones HSM, acceso a claves por parte del proveedor.

Estos puntos no son «nice to have». Deciden si los controles en operación son asumibles y verificables o si tendrán que revisarse manualmente de forma permanente.

5) Consecuencias en costes y operación: la seguridad también supone esfuerzo continuo

Los costes de la nube a menudo se entienden como tarifas de uso. Sin embargo, los costes adicionales relevantes para ISO 27001 suelen derivarse de:

• Operación de identidades (SSO, mantenimiento de roles, recertificación de permisos)
• Logging/Monitoring (volumen de datos, licencias SIEM, retención)
• Gestión de claves y certificados (HSM/Key Vault, rotación, procesos)
• Esfuerzo de auditoría y de evidencias (revisiones de proveedores, evaluaciones anuales, auditorías internas)
• Preparación para la salida (exportación de datos, pruebas de migración, operación en paralelo)

Una plantilla de decisión bien elaborada nombra explícitamente estos costes asociados, para que las medidas de seguridad no comiencen «subfinanciadas».

Controles para la integración en el ISMS: familias de control pragmáticas

En lugar de memorizar números concretos del Annex A, resulta más útil para la implementación estructurar los Cloud-Controls en familias de control. Cada familia debería proporcionar tres elementos: (1) regla/política, (2) implementación técnica, (3) evidencia verificable.

Gobernanza en la nube: políticas, roles, vías de decisión

Sin gobernanza, la seguridad en la nube se convierte en decisiones ad hoc. Como mínimo debería definir:

• Proceso de incorporación de servicios cloud (quién aprueba, qué pasos de verificación, qué requisitos mínimos)
• Modelo de roles (Service Owner, Information Owner, responsables del ISMS, equipo de operación/plataforma, protección de datos)
• Gestión de cambios (cambios de configuración, permisos, integraciones; aprobaciones y documentación)
• Gestión de excepciones (aceptación de riesgo con plazo, medidas compensatorias, fecha de revisión)

Perspectiva de auditoría: los auditores buscan menos «la política perfecta» y más evidencias de que las decisiones se toman de forma consistente, basada en riesgos y repetible.

Gestión de activos y datos: clasificación, residencia de datos, ciclo de vida

En la nube, la clasificación de datos es el ancla: determina qué controles son obligatorios (p. ej., cifrado, RESTricciones de acceso, DLP). Defina:

• Clases de datos (p. ej., público, interno, confidencial, estrictamente confidencial) y ejemplos claros.
• Uso permitido de la nube por clase (qué categorías de servicio están permitidas, qué regiones/ubicaciones).
• Retención y eliminación incluyendo evidencia (solicitudes de eliminación, políticas de retención, requisitos de e-discovery).

Importante para la práctica: en SaaS el «borrado» suele ser un proceso (Soft Delete, Retention, Backups). Su ISMS debe reflejar y evaluar esta realidad, no idealizarla.

Gestión de identidades y accesos (IAM): el hallazgo más frecuente en auditorías cloud

IAM es en proyectos cloud el área con más hallazgos, porque crece rápidamente y está cerca de las áreas de negocio. Controles mínimos:

• SSO y MFA para todas las cuentas privilegiadas, y si es posible para todos los usuarios.
• Least Privilege (permisos mínimos necesarios) y roles en lugar de permisos especiales individuales.
• Joiner/Mover/Leaver: provisión/desprovisión automatizada, idealmente con SCIM.
• Recertificación periódica de permisos (quién revisa, cómo se documenta, qué frecuencia según el riesgo).
• Break-Glass-Accounts: accesos de emergencia con protección robusta, supervisión separada y uso documentado.

Evidencias que aceptan los auditores: exportación de roles, estado de MFA, registros de recertificaciones, tickets/cambios para modificaciones de roles, registro de acciones administrativas.

Cifrado y gestión de claves: de la „casilla marcada“ a una práctica controlada

«Cifrado activado» no es un control mientras los accesos a claves, la rotación y las responsabilidades no estén claras. Para servicios cloud debe definir:

• Cifrado en tránsito: estándares TLS, gestión de certificados, sin protocolos inseguros.
• Cifrado en reposo: cifrado estándar, en su caso claves gestionadas por el cliente (Customer Managed Keys).
• Ciclo de vida de las claves: rotación, acceso (quién puede gestionar las claves), separación de funciones (Separation of Duties).
• Copias de seguridad y exportaciones: cifrado también fuera de la plataforma, especialmente en exportaciones de datos.

Consecuencia práctica: si elige BYOK/CMK, debe ser capaz de operar eso (procesos, monitorización, acceso de emergencia). Sin esa capacidad, «clave propia» suele ser solo un control aparente.

Registro, monitorización y detección: auditable en lugar de «podríamos»

ISO 27001 no exige una solución SIEM concreta, pero sí la capacidad de detectar, investigar y demostrar eventos. En la nube, por tanto, debe aclarar:

• ¿Qué eventos se registran? Autenticación, acciones de administrador, cambios de políticas, exportaciones de datos, llamadas API, errores/anomalías.
• ¿Dónde terminan los logs? Centralizados, protegidos contra manipulación (almacenamiento Write Once / inmutable, en la medida de lo posible), con retención definida.
• ¿Quién responde? Responsabilidades, vías de alarma, disponibilidad/suplencia, runbooks.

Un error habitual en la práctica es «demasiado registro sin plan». Es mejor un perfil de registro basado en riesgos por clase de servicio más un conjunto mínimo que esté siempre activo (especialmente eventos de administrador e IAM).

Ejemplo: Carpeta mínima de evidencias de auditoría por Cloud-Service (propuesta de estructura)
01_Service-Steckbrief.pdf
02_Risikoanalyse_und_Risikobehandlung.pdf
03_SoA_Zuordnung_Controls.pdf
04_Vertrag_und_Sicherheitsanhang.pdf
05_RACI_und_Betriebsmodell.pdf
06_IAM_Rollenexport_MFA_Nachweise/
07_Logging_Forwarding_Nachweise/
08_Change_Records_und_Ausnahmen/
09_Incident_Runbooks_und_Tests/
10_Exit_Plan_und_Exporttests/

Gestión de vulnerabilidades y parches: diferente según el modelo de servicio

Aquí SaaS se diferencia claramente de IaaS:

• SaaS: El proveedor parchea la plataforma y la aplicación. Sus controles residen en la configuración, IAM, integraciones, endpoints y en la valoración de la información de lanzamientos/cambios del proveedor.
• PaaS: El proveedor parchea los servicios base; usted parchea, si procede, runtimes/dependencias en su aplicación. Son importantes las políticas sobre versiones soportadas y despliegues.
• IaaS: Usted parchea sistemas operativos y aplicaciones. Es un programa clásico de parches y hardening, pero con herramientas cloud.

Perspectiva de auditoría: se comprobará si las responsabilidades están claras, si se realiza la evaluación de vulnerabilidades y si existe un procedimiento para aplicar o compensar oportunamente las actualizaciones críticas.

Backup, RESTauración y continuidad del negocio: RTO/RPO y RESTauración real

En proyectos en la nube la disponibilidad a menudo se confunde con «el proveedor es altamente disponible». Para su ISMS, sin embargo, cuentan los requisitos de negocio. Defina:

• RTO/RPO (Recovery Time Objective/Recovery Point Objective): ¿Con qué rapidez y con qué pérdida de datos se permite recuperarse?
• Alcance de la copia de seguridad: Configuraciones (IAM, políticas), datos, material de claves (donde esté permitido), configuraciones de integraciones.
• Pruebas de RESTauración: Frecuencia, criterios de éxito, registros. Sin pruebas, las copias de seguridad son débiles en auditoría.

En SaaS, el punto crítico suele ser: ¿qué opciones de exportación existen? ¿Con qué rapidez obtiene usted los datos en caso de emergencia? ¿Qué dependencias con identidad o correo electrónico impiden el acceso?

Gestión de incidentes y forense: lo que es distinto en la nube

La respuesta a incidentes en la nube es sobre todo una cuestión de acceso a evidencias y coordinación. Defina por servicio:

• Vías de contacto con el proveedor (Security Hotline, prioridad de tickets, escalado).
• Aseguramiento de pruebas: ¿Qué logs, snapshots o exportaciones son posibles? ¿Qué retención está activa?
• Roles: ¿Quién dirige, quién decide sobre desconexión/aislamiento, quién comunica interno/externo?

Una evidencia verificable es un runbook probado (un ejercicio de mesa —tabletop— basta como inicio), incluyendo lecciones aprendidas y seguimiento de medidas.

Gestión de cambios y configuraciones: conforme a la nube, no centrada en servidores

ISO 27001 exige cambios controlados. En la nube eso significa: los cambios suelen producirse en configuraciones, políticas y roles. Controles recomendables son:

• Configuraciones base por clase de servicio (p. ej. MFA activado, registro activado, roles de administrador RESTringidos).
• Registros de cambio para cambios relevantes para la seguridad (permisos, red, claves, registro).
• Revisiones periódicas de configuración y tratamiento de desviaciones.

Si utiliza Infrastructure as Code (IaC): facilita la trazabilidad, pero no es automático. Lo decisivo es el proceso: revisión, aprobación, rollback, y que también se detecten los cambios manuales.

Estrategia de salida y portabilidad: control frente al lock-in y al riesgo operativo

Un plan de salida es, según ISO 27001, un argumento sólido en el tratamiento de riesgos, porque reduce dependencias y aumenta la capacidad de actuación en caso de crisis. Un plan de salida práctico incluye:

• Exportación de datos: formatos, integridad, frecuencia, cifrado, sumas de verificación, responsables.
• Exportación de configuraciones: roles, políticas, integraciones, automatizaciones.
• Ruta de migración: opciones de plataforma destino, dependencias críticas, prueba mínima (p. ej. prueba anual de exportación/RESTore).
• Cláusulas contractuales: plazos, apoyo, eliminación, entrega, costes.

Importante: la salida no es un «proyecto final», sino una capacidad. Pequeñas pruebas periódicas son más económicas que una gran migración bajo presión de tiempo.

Perspectiva de auditoría: qué evidencias en entornos cloud realmente importan

Muchos equipos documentan demasiado en el lugar equivocado (textos extensos) y demasiado poco en el adecuado (artefactos verificables). En auditorías de cloud suelen contar típicamente:

• Alcance e inventario: qué servicios cloud están dentro del alcance del ISMS, con propietarios y finalidad.
• Evaluación de riesgos: riesgos justificables por servicio o por clase de servicio, incluyendo tratamiento de riesgos.
• SoA: selección justificada de controles, incl. implementación/estado.
• Expediente del proveedor: contrato, anexo de seguridad, evidencias/informes, información sobre subcontratistas, revisiones.
• Evidencias operativas: exportaciones de IAM, protocolos de recertificación, reenvío de logs, ejercicios de incidentes, pruebas de RESTore.

Si quiere estructurarse para estar audit-ready, planifique internamente un enlace a una lista de verificación «Audit-Ready». Eso mejora tanto la preparación como la calidad del archivado diario.

Lista de verificación práctica: incorporar un servicio cloud conforme al ISMS en 10 pasos

1. Crear la ficha del servicio (propósito, datos, interfaces, usuarios, propietarios).
2. Definir la clasificación de datos y las regiones/residencia autorizadas.
3. Documentar la Shared Responsibility como RACI por familia de controles.
4. Revisión del proveedor incl. subcontratistas, notificación de incidentes, evidencias.
5. Realizar la evaluación de riesgos, planificar el tratamiento de riesgos (incl. medidas compensatorias).
6. Finalizar contrato/anexo de seguridad (SLA, registro, soporte, salida, info de auditoría).
7. Integrar IAM (SSO, MFA, roles, SCIM, break-glass).

Este orden se ha elegido deliberadamente para que la gobernanza y la generación de evidencias no se implementen a posteriori, sino que la adquisición y la operación sean sólidas desde el inicio.

Responsabilidades y gobernanza en el día a día: ¿quién debe decidir qué?

La integración de la nube en el ISMS fracasa a menudo por supuestos implícitos: ‚Security lo hace‘ o ‚el proveedor es responsable‘. Para decisiones sólidas hacen falta roles claros:

• Service Owner: responsabilidad funcional, presupuesto, acepta riesgos residuales dentro del marco de gobernanza.
• Information Owner: responsable de la necesidad de protección/clasificación de los datos (a menudo el área de negocio, apoyado por IT/Compliance).
• Cloud Platform/Operations: bases técnicas, registro, cuentas, automatización, operación.
• ISMS/Compliance: método, evaluación de riesgos, SoA, generación de evidencias, comunicación de auditoría.
• Security: controles, monitorización, respuesta a incidentes, evaluaciones de excepciones.
• Protección de datos (si procede): bases legales, tratamiento por encargo, transferencias internacionales.

La dirección no es la ‚responsable de los detalles‘, pero debe respaldar la gobernanza: mediante mandatos claros, recursos para los controles y una tolerancia al riesgo definida.

Conclusión: Utilizar servicios en la nube conforme a ISO 27001 significa tomar decisiones controladas

Los servicios en la nube conforme a ISO 27001 no son incompatibles, pero solo son manejables si la selección, el contrato, la configuración y la operación se conciben como un sistema de control coherente. El ajuste central no es una herramienta individual, sino su capacidad para asignar responsabilidades de forma inequívoca, documentar flujos de datos y riesgos, y aplicar controles técnicos de modo que resistan en el día a día y en la auditoría.

Si desea empezar de forma pragmática: establezca un perfil de servicio, un paquete estándar de requisitos mínimos de IAM y registro, un anexo de seguridad para proveedores y una prueba mínima de salida. Con ello reduce significativamente los riesgos típicos de la nube (incertidumbre, falta de evidencias, Lock-in) sin sobrecargar su ISMS con papeleo.

Para este tema también son importantes Isms Cloud Integration y Cloud Governance. El artículo sitúa estos aspectos de forma comprensible y muestra en qué debe centrarse en el día a día.