Gestión de la postura de seguridad de SaaS para auditorías de 2026

El hallazgo de auditoría de SaaS del que nadie era responsable

A las 08:15 de un martes, el CISO de una fintech en rápido crecimiento recibe un mensaje del Delegado de Protección de Datos: “¿Por qué una exportación de clientes puede compartirse públicamente desde una herramienta de colaboración, y quién aprobó la aplicación OAuth que puede leerla?”

A las 09:00, Finanzas confirma que la herramienta se paga con una tarjeta departamental, no mediante compras centralizadas. A las 10:30, TI descubre que el usuario que creó el enlace público dejó la empresa hace tres meses. Al mediodía, Legal pregunta si se trata de una violación de datos personales conforme a GDPR. A las 14:00, el Comité de Riesgos pregunta si el asunto afecta a la ciberhigiene de NIS2 y al riesgo de terceros relacionado con las TIC conforme a DORA. A las 16:00, el auditor interno solicita configuraciones de referencia, revisiones de acceso de administradores, propiedad del servicio en la nube, registros y diligencia debida de proveedores.

La realidad incómoda es que la organización no sufrió una indisponibilidad clásica de SaaS ni un fallo del proveedor. Sufrió un fallo de gobernanza.

Ese escenario ya no es excepcional. Un equipo de marketing conecta una plataforma de IA a un CRM con permisos OAuth amplios. Recursos Humanos compra una herramienta analítica especializada fuera del proceso de compras. Un equipo de atención al cliente habilita exportaciones públicas de tickets por comodidad. Ingeniería integra una extensión de navegador en un flujo de trabajo de desarrollo. Cada decisión puede parecer menor, pero en conjunto crean una superficie de control distribuida, cargada de datos regulados, flujos de trabajo privilegiados y dependencias operativas.

La gestión de la postura de seguridad de SaaS, o SSPM, es la disciplina que convierte esa realidad SaaS dispersa en un control gobernado, probado y auditable. Bien ejecutada, proporciona a CISO, responsables de cumplimiento, auditores y propietarios de negocio una única pista de evidencias para ISO/IEC 27001:2022, la ciberhigiene de NIS2, el riesgo relacionado con las TIC de DORA y la responsabilidad proactiva de seguridad de GDPR.

La posición de Clarysec es clara: SSPM no debe tratarse como otro panel más. Debe integrarse en el SGSI, vincularse a la propiedad del riesgo, mapearse a las obligaciones legales, apoyarse en políticas y probarse mediante evidencias recurrentes.

Ahí es donde Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, Zenith Controls: guía de cumplimiento transversal Zenith Controls y las plantillas de políticas de Clarysec resultan prácticas. Ayudan a convertir la proliferación de SaaS en un modelo de control que un auditor puede entender y que un órgano de dirección puede supervisar.

Por qué la gestión de la postura de seguridad de SaaS se convirtió en un asunto de cumplimiento

SaaS solía tratarse como “software que ejecuta otro”. Ese enfoque ya no es defendible.

Bajo NIS2, muchos proveedores de nube, SaaS, infraestructura digital, servicios gestionados y seguridad gestionada pueden quedar sujetos a expectativas regulatorias de ciberseguridad en función del sector, tamaño, función y criticidad. Más importante aún, las organizaciones que dependen de SaaS deben gobernarlo como parte de sus propias medidas de gestión de riesgos. NIS2 Article 20 responsabiliza a los órganos de dirección de aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implantación y recibir formación. Article 21 exige medidas técnicas, operativas y organizativas prácticas, incluidos análisis de riesgos, políticas, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y mantenimiento seguros, pruebas de eficacia, ciberhigiene, criptografía, seguridad de Recursos Humanos, control de acceso, gestión de activos y autenticación multifactor cuando proceda.

DORA eleva aún más el listón para las entidades financieras. Desde el 17 de enero de 2025, DORA se aplica a muchas organizaciones del sector financiero como régimen de resiliencia operativa para las entidades dentro de su alcance. Exige gobernanza de las TIC, identificación y clasificación de activos TIC y funciones soportadas, controles de protección y prevención, gestión de incidentes, continuidad, pruebas y gestión del riesgo de terceros relacionado con las TIC. Los proveedores SaaS que soportan funciones críticas o importantes pasan a formar parte del perímetro de evidencias de DORA, mientras que la entidad financiera regulada conserva la responsabilidad.

GDPR añade una capa de evidencias de privacidad. Article 5 exige integridad, confidencialidad y responsabilidad proactiva. Article 32 exige una seguridad adecuada del tratamiento. En la práctica, una organización debe saber qué datos personales existen, dónde se tratan, quién puede acceder a ellos, qué proveedores los tratan y qué salvaguardas los protegen. Una configuración incorrecta de SaaS convierte esas preguntas en cuestiones urgentes de evaluación de una violación de seguridad.

ISO/IEC 27001:2022 es el puente. Las cláusulas 4.1 a 4.4 exigen que la organización defina el contexto, los requisitos de las partes interesadas, el alcance, las interfaces y las dependencias. La cláusula 5 exige liderazgo, política, roles y responsabilidad proactiva. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, Declaración de Aplicabilidad y decisiones sobre riesgo residual. Las cláusulas 8.1, 8.2 y 8.3 exigen planificación operacional, evaluación de riesgos y tratamiento de riesgos. Las cláusulas 9 y 10 exigen seguimiento, auditoría interna, revisión por la dirección y mejora.

Si no puede responder qué herramientas SaaS tratan datos regulados, quién es su propietario, cómo están configuradas, quién tiene acceso de administrador, qué integraciones están activas y qué evidencias demuestran que el control funciona, su posición de cumplimiento es frágil.

El modelo SSPM de Clarysec: inventario, propiedad, configuración de referencia y evidencias

Clarysec trata la gestión de la postura de seguridad de SaaS como un ciclo de control repetible, no como un proyecto puntual de saneamiento.

1. Descubrir todos los servicios SaaS, incluido el shadow SaaS.
2. Asignar un propietario de negocio y un propietario técnico.
3. Clasificar datos, usuarios, integraciones y criticidad operativa.
4. Aplicar configuraciones de referencia seguras.
5. Revisar usuarios, administradores, invitados, cuentas de servicio y alcances OAuth.
6. Habilitar registro, alertas y conservación.
7. Supervisar el uso compartido público y la exposición de datos.
8. Vincular proveedores, contratos, contratos de encargo de tratamiento y planificación de salida.
9. Recopilar evidencias con una periodicidad definida.
10. Incorporar los hallazgos al tratamiento de riesgos, la revisión por la dirección y la mejora.

Este modelo se alinea estrechamente con los controles de ISO/IEC 27002:2022 ISO/IEC 27002:2022, especialmente 5.9 inventario de información y otros activos asociados, 5.15 control de acceso, 5.18 derechos de acceso, 5.19 seguridad de la información en las relaciones con proveedores, 5.20 tratamiento de la seguridad de la información en acuerdos con proveedores, 5.21 gestión de la seguridad de la información en la cadena de suministro de TIC, 5.23 seguridad de la información para el uso de servicios en la nube, 8.2 derechos de acceso privilegiado, 8.3 restricción de acceso a la información, 8.9 gestión de configuraciones, 8.15 registro, 8.16 actividades de supervisión y 8.32 gestión de cambios.

El Zenith Blueprint, en la fase de controles en acción, paso 23 para controles organizativos, establece:

La nube ya no es un destino; es el valor por defecto. Desde el almacenamiento hasta la colaboración, desde la infraestructura hasta el aprendizaje automático, las organizaciones se construyen cada vez más sobre capas de entornos de terceros, abstraídos y gestionados de forma remota. El control 5.23 reconoce esta realidad y exige que la seguridad de la información se aborde explícitamente en la selección, el uso y la gestión de los servicios en la nube, no como una consideración posterior, sino como un principio de diseño desde el inicio.

Ese es el núcleo de SSPM. No consiste solo en detectar una configuración incorrecta a posteriori. Consiste en hacer que la selección, el alta, la operación, la supervisión y la salida de SaaS formen parte del sistema de gestión.

La misma sección de Zenith Blueprint explica la realidad de la responsabilidad compartida con un lenguaje que todo miembro del consejo de administración debería escuchar:

Los proveedores de nube protegen la infraestructura, pero usted sigue siendo responsable de sus datos, sus configuraciones, sus políticas de acceso y su preparación para respuesta a incidentes. Un bucket de almacenamiento mal configurado, un panel expuesto públicamente o permisos excesivos en una configuración IAM en la nube no son fallos de la nube. Son fallos de gobernanza.

Su proveedor puede operar la plataforma, pero usted sigue siendo responsable de la configuración del tenant, las identidades, las aprobaciones de acceso, los datos expuestos, las integraciones, los flujos de trabajo de incidentes y las evidencias de cumplimiento.

El control 5.23 es el ancla, pero SSPM necesita una familia de controles

En Zenith Controls, el control 5.23 de ISO/IEC 27002:2022, seguridad de la información para el uso de servicios en la nube, se clasifica como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad. Su concepto de ciberseguridad es Protect, con capacidad operativa en seguridad de las relaciones con proveedores y dominios de gobernanza, ecosistema y protección.

Esto importa porque SSPM no es un control único. Es una disciplina de controles transversal.

Zenith Controls vincula 5.23 con las relaciones con proveedores bajo 5.19 porque los proveedores SaaS son proveedores críticos, pero 5.23 añade preocupaciones específicas de SaaS, como la multitenencia, la transparencia sobre la ubicación de los datos y la responsabilidad compartida. Vincula 5.23 con la transferencia de información porque las interfaces de programación de aplicaciones, integraciones y flujos de trabajo entre SaaS mueven datos constantemente. Vincula 5.23 con el inventario de activos porque las organizaciones necesitan visibilidad actualizada sobre datos almacenados en la nube y recursos SaaS. También vincula la gobernanza de la nube con la supervisión, la restricción de acceso, la gestión de configuraciones y la supervisión de proveedores.

Para los derechos de acceso, Zenith Controls mapea 5.18 con 5.15 control de acceso, 5.16 gestión de identidades, 5.3 segregación de funciones, 5.36 cumplimiento de políticas, reglas y estándares de seguridad de la información y 8.2 derechos de acceso privilegiado. Para SSPM, esto significa que la revisión de accesos no es solo un ejercicio de hoja de cálculo. Es una prueba operativa de que el ciclo de vida de la identidad, el mínimo privilegio, la segregación de funciones y la gobernanza de accesos privilegiados funcionan dentro de las aplicaciones SaaS.

Base de políticas: definir lo correcto antes de comprar herramientas

Muchos fallos de SaaS empiezan porque el lenguaje de las políticas es vago. “Usar herramientas aprobadas de forma segura” no basta. Las políticas de Clarysec definen expectativas específicas sobre inventarios, acceso, registro de eventos, configuración y revisión de proveedores.

Para pymes, la Política de Uso de la Nube para pymes Política de Uso de la Nube - pyme ofrece un punto de partida práctico. De la sección “Requisitos de gobernanza”, cláusula 5.3 de la política:

El proveedor de TI o el DG debe 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 equipo responsable (Propietario de la aplicación) 5.3.3 Los tipos de datos almacenados o tratados 5.3.4 El país o 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

Esta cláusula es el núcleo operativo de SSPM. Proporciona a los auditores el primer objeto de evidencia: un registro que conecta el uso de SaaS con propietarios, datos, geografía, acceso y contratos.

La misma Política de Uso de la Nube para pymes, de la sección “Requisitos de implementación de la política”, cláusula 6.2 de la política, define los ajustes de referencia:

Requisitos de configuración de seguridad 6.2.1 Debe habilitarse lo siguiente en todas las plataformas en la nube: 6.2.2 Autenticación multifactor (MFA) para cuentas administrativas y de usuario 6.2.3 Ajustes de complejidad de contraseña (mínimo 10 caracteres, sin reutilización) 6.2.4 Registro de actividad para intentos de inicio de sesión y acceso a datos 6.2.5 Restricciones de acceso (p. ej., listas de permitidos de IP, cuando estén soportadas) 6.2.6 El acceso administrativo debe limitarse a personas nominales o proveedores de soporte autorizados. 6.2.7 El contenido compartido públicamente debe supervisarse periódicamente para prevenir la fuga de datos. 6.2.8 Cuando las cuentas de usuario ya no sean necesarias, el acceso debe revocarse inmediatamente y cualquier dato residual debe revisarse y archivarse o eliminarse.

Para entornos empresariales, la Política de Uso de la Nube Política de Uso de la Nube asigna una gobernanza centralizada más sólida. De la sección “Requisitos de gobernanza”, cláusula 5.3 de la política:

Cada servicio en la nube debe tener un propietario del servicio asignado, responsable de la gestión del ciclo de vida de los activos de información, la gobernanza del uso, el seguimiento presupuestario y la supervisión continua del cumplimiento.

Esa frase cierra una brecha de auditoría habitual. Si nadie es propietario de un servicio SaaS, nadie es responsable de la desviación de la configuración de referencia, la recertificación de accesos, la exposición de datos, las decisiones de renovación, el contacto en incidentes o la planificación de salida.

La gobernanza de privilegios también debe ser explícita. La Política de gestión de cuentas de usuario y privilegios para pymes Política de gestión de cuentas de usuario y privilegios - pyme, de la sección “Requisitos de implementación de la política”, cláusula 6.4 de la política, establece:

Revisiones de acceso y registro 6.4.1 Debe realizarse una revisión de todas las cuentas de usuario y privilegios cada seis meses. 6.4.2 Durante las revisiones, el responsable de TI debe validar si cada cuenta sigue activa, es necesaria y tiene asignados los permisos correctos. 6.4.3 Los registros de creación de cuentas, desactivación de cuentas y cambios de privilegios deben conservarse de forma segura durante al menos 12 meses.

En SaaS, toda plataforma crítica necesita un ciclo definido de revisión de accesos, incluso si la plataforma la administra un equipo de negocio y no TI central.

El registro también debe ser explícito. La Política de registro y supervisión para pymes Política de registro y supervisión - pyme, de la sección “Requisitos de gobernanza”, cláusula 5.5 de la política, establece:

Servicios en la nube y registro de terceros 5.5.1 Para plataformas en las que el registro no está bajo control directo de TI (p. ej., correo electrónico SaaS), se aplican los siguientes requisitos: 5.5.1.1 El registro debe habilitarse y configurarse 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 a los proveedores conservar los registros durante al menos 12 meses y facilitar acceso previa solicitud

Por último, la gobernanza de proveedores SaaS debe documentarse. La Política de Seguridad de Terceros y Proveedores para pymes Política de Seguridad de Terceros y Proveedores - pyme, de la sección “Requisitos de implementación de la política”, cláusula 6.3 de la política, establece:

Supervisión continua de la seguridad de proveedores 6.3.1 Los proveedores críticos o de alto riesgo deben revisarse al menos anualmente. La revisión debe verificar: 6.3.1.1 Uso continuado de métodos de acceso seguros 6.3.1.2 Certificaciones de seguridad válidas o evidencias de control actualizadas 6.3.1.3 Historial de incidentes o problemas comunicados 6.3.1.4 Cumplimiento contractual de las cláusulas de seguridad 6.3.2 Estas revisiones deben documentarse y conservarse con el registro del proveedor. Las acciones de seguimiento deben quedar claramente trazadas. 6.3.3 Cuando los proveedores gestionen infraestructura de TI o aplicaciones, la supervisión puede incluir: 6.3.3.1 Solicitud de registros de auditoría 6.3.3.2 Revisión de la actividad de cuentas 6.3.3.3 Confirmación de que no se ha producido acceso no autorizado

En conjunto, estas políticas convierten SSPM de una aspiración de seguridad en un modelo operativo exigible.

Un sprint de 30 días de evidencias SSPM

Un CISO o responsable de cumplimiento pragmático puede empezar con un sprint de 30 días de evidencias. Seleccione las cinco plataformas SaaS más relevantes para datos regulados u operaciones críticas. Los candidatos típicos incluyen Microsoft 365 o Google Workspace, CRM, sistema de tickets, HRIS, automatización financiera, atención al cliente y analítica.

Semana 1: Crear el registro de SaaS

Use los campos de la cláusula 5.3 de la Política de Uso de la Nube para pymes como registro mínimo. Para cada servicio SaaS, capture:

• Nombre del servicio y finalidad de negocio
• Propietario de la aplicación y propietario técnico
• Tipos de datos, incluidos datos personales y datos de categorías especiales cuando proceda
• País o región de almacenamiento de datos
• Grupos de usuarios y cuentas de administrador
• Aplicaciones OAuth e integraciones de terceros
• Propietario del contrato, fecha de renovación y contacto de soporte
• Criticidad para las operaciones
• Obligaciones aplicables, como NIS2, DORA, GDPR o contratos de clientes

Esto respalda las cláusulas 4.2 y 4.3 de ISO/IEC 27001:2022 porque las dependencias regulatorias, contractuales y de terceros deben configurar el alcance del SGSI. También respalda la identificación y clasificación, al estilo de DORA Article 8, de funciones de negocio soportadas por TIC, activos de información, activos TIC y dependencias.

Semana 2: Definir configuraciones de referencia seguras

Para cada plataforma SaaS seleccionada, defina entre 10 y 15 controles de referencia.

• MFA aplicada a todos los usuarios, con MFA resistente al phishing para administradores cuando sea posible
• Uso compartido externo deshabilitado por defecto o limitado a dominios aprobados
• Enlaces públicos deshabilitados o limitados en el tiempo
• Cuentas de invitados revisadas mensualmente
• Roles de administrador asignados a personas nominales
• Autenticación heredada deshabilitada
• Flujo de aprobación de aplicaciones OAuth habilitado
• Alcances OAuth de alto riesgo bloqueados o sujetos a aprobación de seguridad
• Registro de auditoría habilitado
• Permisos de exportación de datos restringidos
• Ajustes de conservación alineados con requisitos legales y de negocio
• Tokens de interfaces de programación de aplicaciones revisados y rotados
• Alertas de seguridad enrutadas a TI o al SOC
• Ajustes de Prevención de pérdida de datos (DLP) habilitados cuando estén soportados
• Cuentas break-glass documentadas y supervisadas

El Zenith Blueprint, fase de controles en acción, paso 19, control 8.9 gestión de configuraciones, explica por qué esto importa:

Muchas brechas de seguridad no se deben a defectos de software, sino a malas decisiones de configuración. Contraseñas por defecto sin cambiar, servicios inseguros habilitados, puertos innecesarios abiertos o sistemas expuestos a internet sin justificación. El control 8.9 garantiza que todo sistema se construya sobre una configuración de referencia segura y se revise periódicamente para prevenir la deriva con el tiempo.

En SaaS, la desviación de la configuración de referencia incluye que un propietario de negocio habilite el uso compartido público, que un administrador apruebe accesos amplios de terceros o que un proveedor cambie valores por defecto tras una versión de funcionalidad.

Semana 3: Revisar accesos e integraciones

Exporte usuarios, grupos, administradores y aplicaciones conectadas. Para cada cuenta de administrador, confirme la persona nominal, la justificación de negocio, el estado de MFA, el último inicio de sesión, el nivel de privilegio, la cobertura de respaldo, las cuestiones de segregación de funciones y las evidencias de aprobación.

Para aplicaciones e integraciones OAuth, confirme el propietario de la aplicación, los datos accedidos, los permisos solicitados, el estado de riesgo del proveedor, la fecha de último uso, la necesidad vigente y si el consentimiento fue concedido por el usuario o aprobado por un administrador.

El Zenith Blueprint, fase de controles en acción, paso 19, control 8.3 restricción de acceso a la información, proporciona el principio operativo:

El acceso a la información debe ser tan abierto como sea necesario, pero tan restringido como sea posible.

Esto se aplica no solo a las personas, sino también a aplicaciones, servicios e interfaces de programación de aplicaciones. Una integración OAuth inactiva puede conservar el acceso mucho después de que el empleado o proyecto que la creó haya desaparecido.

Semana 4: Producir evidencias preparadas para auditoría y tratamiento de riesgos

Para cada plataforma SaaS, almacene la entrada del registro, la configuración de referencia, capturas de pantalla o exportaciones que prueben los ajustes clave, la aprobación de la revisión de accesos, las evidencias de revisión de administradores, las evidencias de revisión OAuth, las evidencias de registro y alertas, el registro de revisión de seguridad del proveedor, los hallazgos abiertos y las acciones de tratamiento de riesgos.

Después, cree un resumen ejecutivo de una página que muestre hallazgos críticos, propietarios vencidos, brechas de configuración de alto riesgo no resueltas, integraciones no aprobadas, deficiencias de registro, excepciones y decisiones necesarias. Esto respalda la cláusula 9.1 de ISO/IEC 27001:2022 sobre seguimiento, la cláusula 9.2 sobre auditoría interna y la cláusula 9.3 sobre revisión por la dirección. También crea un puente práctico hacia la responsabilidad proactiva de la dirección conforme a NIS2 Article 20 y la supervisión del órgano de dirección conforme a DORA.

Mapeo de cumplimiento transversal: un paquete de evidencias SSPM, muchas obligaciones

El valor de negocio de SSPM no es solo una mejor seguridad. Es la reducción de la duplicación de cumplimiento.

NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas. El inventario de SaaS respalda la gestión de activos. Las configuraciones de referencia respaldan la ciberhigiene. MFA y las revisiones de acceso respaldan el control de acceso. El registro respalda la gestión de incidentes. La revisión de proveedores respalda la seguridad de la cadena de suministro. La cadencia de evidencias respalda las políticas y procedimientos para evaluar la eficacia.

DORA exige a las entidades financieras identificar y clasificar funciones soportadas por TIC, activos de información, activos TIC y dependencias de terceros. También exige medidas de protección y prevención, controles de acceso, autenticación fuerte, cifrado, continuidad, pruebas, gestión de incidentes y gobernanza del riesgo de terceros relacionado con las TIC. Un paquete de evidencias SSPM de SaaS puede respaldar registros DORA, mapeo de dependencias, supervisión contractual, derechos de auditoría y planificación de salida.

GDPR exige a los responsables del tratamiento demostrar cumplimiento de integridad, confidencialidad y responsabilidad proactiva. Los registros SaaS identifican dónde se tratan datos personales. Las configuraciones de referencia reducen la divulgación no autorizada. Las revisiones de acceso respaldan el mínimo privilegio. El registro respalda la investigación de violaciones de seguridad. Los registros de proveedores respaldan la gobernanza de encargados y la responsabilidad proactiva.

NIST CSF 2.0 añade una capa de comunicación útil. Su función GOVERN exige que los requisitos legales, regulatorios y contractuales de ciberseguridad se comprendan y gestionen. Sus resultados de cadena de suministro exigen roles de proveedores, contratos, diligencia debida, supervisión y actividades posteriores a la relación. Sus funciones IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER se mapean de forma natural al inventario de SaaS, control de acceso, protección de datos, registro, respuesta a incidentes y recuperación.

COBIT 2019 y los auditores orientados a ISACA suelen abordar SSPM desde la gobernanza, los objetivos de gestión, la propiedad del riesgo, la operación de controles y el aseguramiento. Preguntarán si las decisiones SaaS están alineadas con los objetivos empresariales, si las respuestas al riesgo están documentadas, si las responsabilidades están asignadas y si las actividades de aseguramiento prueban que los controles operan.

La perspectiva de auditoría: cómo prueban los distintos auditores la postura SaaS

Un programa SSPM sólido resiste distintos estilos de auditoría porque produce evidencias al nivel adecuado.

Un auditor de ISO/IEC 27001:2022 empezará por el alcance, las partes interesadas, la evaluación de riesgos, la Declaración de Aplicabilidad y las evidencias operativas. Si se incluye el control 5.23, esperará evidencias de selección, uso, gestión y salida de servicios en la nube. Si se incluyen controles de derechos de acceso, muestreará usuarios y preguntará si los cambios de altas, modificaciones y bajas se reflejan en los permisos SaaS.

Un revisor de DORA se centrará en funciones críticas o importantes, dependencia de terceros TIC, completitud de registros, contratos, clasificación de incidentes, pruebas y planificación de salida. Si una plataforma SaaS soporta operaciones de pago, incorporación de clientes, negociación, analítica de riesgos o comunicaciones con clientes, el estándar de evidencias aumenta.

Un auditor de GDPR o revisor de privacidad preguntará dónde se almacenan los datos personales, quién puede acceder a ellos, qué exportaciones y ajustes de uso compartido existen, si los encargados están gobernados, si los registros respaldan la evaluación de violaciones de seguridad y si los controles son proporcionales al riesgo.

Riesgo de proveedores, responsabilidad compartida y preparación para incidentes

SSPM suele empezar con la configuración, pero no puede detenerse ahí. SaaS también es una cuestión de riesgo de proveedores y preparación para incidentes.

DORA exige a las entidades financieras mantener registros de contratos de servicios TIC, distinguir acuerdos que soportan funciones críticas o importantes, evaluar el riesgo de concentración, valorar la idoneidad del proveedor y mantener estrategias de salida. Los contratos deben abordar descripciones del servicio, ubicación de los datos, protección de la disponibilidad, autenticidad, integridad y confidencialidad, acceso a datos, recuperación y devolución, asistencia en incidentes, cooperación con autoridades, derechos de terminación, requisitos de seguridad, derechos de auditoría y soporte de transición.

NIS2 Article 21 también incluye la seguridad de la cadena de suministro y exige que las entidades consideren vulnerabilidades específicas de proveedores directos y proveedores de servicios, la calidad de los productos y las prácticas de ciberseguridad de los proveedores.

En la práctica, una revisión SaaS crítica debe combinar evidencias de cuestionarios de seguridad, revisión contractual, estado del contrato de encargo de tratamiento, historial de incidentes, compromisos de nivel de servicio, acceso a registros, informes de auditoría, evidencias de configuración y viabilidad de salida.

La brecha de responsabilidad compartida aparece cuando los equipos asumen que la certificación del proveedor cubre la configuración del tenant. No lo hace. Un proveedor puede operar una plataforma segura mientras el cliente habilita el uso compartido público, deja activas cuentas de administrador inactivas o concede alcances excesivos de interfaces de programación de aplicaciones. SSPM cierra esa brecha.

La preparación para incidentes es igualmente importante. La notificación de incidentes significativos de NIS2 incluye una alerta temprana en 24 horas, una notificación en 72 horas y un informe final a más tardar un mes después de la notificación de 72 horas. DORA exige gestión de incidentes relacionados con las TIC con detección, registro, clasificación, escalado, comunicación y notificación. La evaluación de violaciones de datos personales conforme a GDPR también depende de entender oportunamente qué ocurrió, qué datos se vieron afectados y quién resultó impactado.

Si una aplicación OAuth sospechosa accedió a archivos de clientes, necesita saber cuándo se autorizó la aplicación, qué usuario la autorizó, qué alcances se concedieron, a qué datos se accedió, si los datos se descargaron o compartieron, qué usuarios o clientes se vieron afectados, si el acceso sigue activo y qué acciones de contención se tomaron.

Sin registro y conservación, la organización puede verse obligada a asumir el peor caso. Eso aumenta la exposición legal, la presión de comunicación a clientes y la incertidumbre regulatoria. Cuando un proveedor SaaS cobra un coste adicional por los registros de auditoría, el Propietario del Riesgo debe aceptar explícitamente el riesgo residual o aprobar el nivel de licencia requerido. Esa decisión debe constar en el registro de tratamiento de riesgos y en la revisión por la dirección.

Patrones comunes de fallo de SSPM

Los mismos patrones de fallo aparecen en todos los sectores.

Primero, el shadow SaaS se descubre a través de facturas, historial del navegador o registros de SSO, no mediante compras. La corrección no consiste solo en bloquear herramientas. Consiste en un proceso ligero de incorporación que los equipos de negocio puedan usar.

Segundo, la propiedad de SaaS no está clara. El CRM “pertenece a Ventas”, pero nadie en Ventas puede explicar los roles de administrador, tokens de interfaces de programación de aplicaciones, exportaciones de datos o ajustes de conservación. Asigne por separado propietarios de aplicaciones y propietarios técnicos.

Tercero, las revisiones de acceso son demasiado genéricas. Un revisor aprueba “todos los usuarios aprobados” sin comprobar roles de alto riesgo, usuarios inactivos, invitados, colaboradores externos o cuentas de servicio. La revisión de accesos SSPM debe priorizarse por riesgo.

Cuarto, las aplicaciones OAuth se ignoran. Muchas organizaciones revisan usuarios humanos, pero no permisos entre aplicaciones. En el SaaS moderno, las integraciones pueden ser más potentes que los usuarios.

Quinto, las configuraciones de referencia existen solo como capturas de pantalla del proyecto de certificación. No se supervisan frente a desviaciones. Alinee SSPM con la gestión de configuraciones para que las comprobaciones de referencia se conviertan en evidencias recurrentes.

Sexto, la revisión de proveedores y la revisión de la postura SaaS están separadas. Compras tiene el contrato, TI tiene la consola de administración, Privacidad tiene el contrato de encargo de tratamiento y Seguridad tiene el Registro de Riesgos. El auditor ve fragmentos. SSPM los reúne.

Informes a la dirección: hacer visible el riesgo SaaS para el consejo

NIS2 y DORA convierten la gobernanza de TIC y ciberseguridad en un asunto de dirección. ISO/IEC 27001:2022 también exige liderazgo, recursos, asignación de roles, supervisión y revisión por la dirección.

Un informe de gestión SSPM eficaz debe responder:

• ¿Qué servicios SaaS críticos están dentro del alcance?
• ¿Qué procesos regulados dependen de ellos?
• ¿Cuáles contienen datos personales o datos sensibles de negocio?
• ¿Cuáles tienen revisiones de acceso vencidas?
• ¿Cuáles tienen brechas de configuración de alto riesgo no resueltas?
• ¿Cuáles tienen aplicaciones o integraciones OAuth no aprobadas?
• ¿Qué proveedores carecen de evidencias de seguridad actualizadas?
• ¿Qué deficiencias de registro afectan a la notificación de incidentes?
• ¿Qué excepciones requieren aceptación del riesgo?
• ¿Qué inversiones o decisiones son necesarias?

Esto transforma SSPM de un proyecto técnico de saneamiento en una entrada de gobernanza. También hace más eficaz al CISO porque la aceptación del riesgo se desplaza al nivel adecuado.

Convertir la postura SaaS en evidencias preparadas para auditoría

Si su organización depende de SaaS para datos regulados, operaciones financieras, atención al cliente, Recursos Humanos, colaboración, ingeniería o analítica, SSPM ya no es opcional. Forma parte de la ciberhigiene, la gestión del riesgo relacionado con las TIC, la responsabilidad proactiva de privacidad y la preparación para auditorías.

Clarysec puede ayudarle a pasar de hallazgos SaaS dispersos a un programa estructurado y basado en evidencias mediante:

• Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint para estructurar la implementación en uso de la nube, restricción de acceso y gestión de configuraciones.
• Zenith Controls: guía de cumplimiento transversal Zenith Controls para mapear los controles ISO/IEC 27002:2022 con NIS2, DORA, GDPR, NIST CSF 2.0 y expectativas de auditoría.
• Plantillas de políticas de Clarysec como Política de Uso de la Nube Política de Uso de la Nube, Política de Uso de la Nube para pymes Política de Uso de la Nube - pyme, Política de gestión de cuentas de usuario y privilegios para pymes Política de gestión de cuentas de usuario y privilegios - pyme, Política de registro y supervisión para pymes Política de registro y supervisión - pyme y Política de Seguridad de Terceros y Proveedores para pymes Política de Seguridad de Terceros y Proveedores - pyme para crear reglas operativas exigibles.

Empiece con sus cinco plataformas SaaS de mayor riesgo. Asigne propietarios. Capture datos, acceso, configuración, integraciones, registros y evidencias de proveedores. Convierta los hallazgos en acciones de tratamiento de riesgos y decisiones de dirección.

Así es como la gestión de la postura de seguridad de SaaS se convierte en algo más que una categoría de herramientas. Se convierte en una disciplina de cumplimiento defendible para 2026.

Descargue las plantillas de políticas de Clarysec, use Zenith Blueprint para planificar su sprint de 30 días de evidencias SSPM y mapee sus controles SaaS con Zenith Controls antes de que su próxima auditoría encuentre las brechas por usted.