Por qué los clientes de un SaaS piden ISO 27001
En una empresa SaaS, la ISO 27001 suele llegar por compras. Un cliente grande hace su evaluación de proveedores, el cuestionario de seguridad pide un certificado y la operación se queda parada hasta que existe. El comprador quiere una garantía independiente de que el proveedor gestiona la seguridad de la información de forma sistemática, y un certificado ISO 27001 emitido por una entidad de certificación acreditada es la forma más reconocida de darla en Europa.
El certificado rara vez cierra la evaluación por sí solo. El comprador lee el alcance impreso en él y muchas veces pide la declaración de aplicabilidad. Los dos documentos tienen que demostrar que el producto que compra está cubierto. Por eso el alcance es la primera decisión que importa.
Definir el alcance en torno al producto
El apartado 4.3 de ISO 27001:2022 exige definir los límites del sistema de gestión de seguridad de la información, el SGSI, teniendo en cuenta las interfaces y dependencias con actividades externas a él. En una empresa SaaS, el alcance práctico es el producto que compran los clientes y todo lo que lo presta: el entorno cloud de producción, los repositorios de código y la cadena de despliegue, los equipos que desarrollan, operan y dan soporte al producto, y los proveedores de los que depende el servicio.
Las áreas de la empresa que no tocan el producto pueden quedar fuera, pero hay que describir las interfaces. Un alcance que deja fuera al equipo de ingeniería, o que nombra la empresa pero no el producto, genera preguntas del auditor y de los clientes. La diferencia entre un SGSI real y un conjunto de documentos se explica en nuestro artículo sobre qué es un SGSI y en qué se diferencia de tener políticas.
Los controles del Anexo A que más pesan
ISO 27001:2022 incluye 93 controles en el Anexo A, agrupados en temas organizativos, de personas, físicos y tecnológicos. Todos se consideran en el tratamiento de riesgos y cada exclusión se justifica en la declaración de aplicabilidad. En una empresa SaaS, unos pocos grupos concentran la mayor parte del peso:
- Servicios en la nube, control 5.23, añadido en la revisión de 2022, que cubre cómo la empresa adquiere, usa, gestiona y abandona los servicios cloud de los que depende.
- Relación con proveedores, controles 5.19 a 5.22, con requisitos de seguridad en los contratos y seguimiento de los servicios prestados.
- Desarrollo seguro, controles 8.25 a 8.29, desde el ciclo de vida de desarrollo seguro hasta las pruebas de seguridad durante el desarrollo y la aceptación.
- Separación de entornos y gestión de cambios, controles 8.31 y 8.32.
- Configuración, vulnerabilidades, registro y monitorización, controles 8.8, 8.9, 8.15 y 8.16.
- Copias de seguridad y gestión de incidentes, control 8.13 y controles 5.24 a 5.28.
La selección la marca el análisis de riesgos, no una plantilla. Una empresa sin oficina física también considera los controles físicos, pero su justificación remitirá a su proveedor cloud y a su política de teletrabajo.
La responsabilidad compartida con el proveedor cloud
Los grandes proveedores cloud tienen certificados ISO 27001 para sus propios servicios. Esos certificados cubren su capa: los centros de datos, el hardware y los servicios tal como los opera el proveedor. No cubren cómo configura la empresa SaaS sus cuentas, quién accede a ellas ni qué despliega encima.
El control 5.23 pide a la empresa definir y gestionar ese reparto. En la práctica significa saber qué servicios se usan, qué responsabilidades de seguridad se quedan en la empresa y cómo se revisan los certificados e informes del proveedor. ISO/IEC 27017, un código de buenas prácticas para servicios en la nube, e ISO/IEC 27018, sobre datos personales en nubes públicas, dan orientaciones útiles para este trabajo. No son obligatorias para certificarse en ISO 27001.
Qué revisa el auditor en una empresa SaaS
La auditoría de certificación se hace en dos fases, que explicamos en nuestro artículo sobre la fase 1 y la fase 2 de la auditoría ISO 27001. En la fase 2 el auditor toma muestras de registros del SGSI en funcionamiento. En una empresa SaaS las muestras habituales son estas: peticiones de cambio con su aprobación y sus pruebas, revisiones de acceso a producción y a la consola cloud, altas y bajas de personal con las fechas en que se concedió y retiró el acceso, vulnerabilidades detectadas con sus tickets de corrección, pruebas de restauración de copias, registros de incidentes y revisiones de proveedores.
Cada muestra tiene que existir antes de la auditoría. Una cadena de despliegue que obliga a revisar cada cambio genera la evidencia sola. Una revisión trimestral de accesos que nadie programó, no. Aquí es donde la parte operativa de la seguridad decide si se obtiene el certificado y si sobrevive a la primera auditoría de seguimiento. Las pruebas de seguridad son una carencia frecuente; nuestro artículo sobre pruebas de seguridad de aplicaciones explica qué espera en la práctica el control 8.29.
ISO 27001 o SOC 2
Las empresas SaaS que venden fuera de España suelen encontrarse con ISO 27001 y con SOC 2. Se solapan mucho en controles y evidencias, pero son instrumentos distintos: ISO 27001 certifica un sistema de gestión, mientras que un informe SOC 2 es la opinión de un auditor sobre los controles frente a los criterios de servicios de confianza del AICPA. Los compradores europeos suelen pedir ISO 27001 y los estadounidenses, SOC 2. Nuestro artículo sobre qué tienen en común ISO 27001, SOC 2 y TISAX explica cómo trabajar con un único conjunto de controles.
Dónde encaja Qalea
Una empresa SaaS de tamaño medio rara vez tiene un equipo de seguridad propio cuando un cliente le pide la ISO 27001. Qalea combina una plataforma de cumplimiento para el SGSI con una capa operada de EDR, SIEM, SOC, pruebas de intrusión y vCISO. Dejamos el SGSI preparado para la auditoría y hacemos el trabajo de seguridad que mantiene el certificado válido. Más sobre la norma en nuestro espacio dedicado a ISO 27001.
