Un programa que no instalamos: ¿qué es SaaS?
Imagina una herramienta para aprobar gastos, gestionar vacaciones o seguir oportunidades comerciales. En lugar de comprar un programa e instalarlo en los servidores de la empresa, accedemos a través de una web y pagamos por utilizarlo. El proveedor opera la aplicación y normalmente se ocupa de su infraestructura, mantenimiento y evolución. A eso se llama software como servicio, o SaaS.
La definición formal del NIST describe aplicaciones que ejecuta el proveedor en infraestructura cloud y a las que el cliente accede por navegador o interfaz. El cliente no controla normalmente los servidores y sistemas operativos subyacentes. Esa distribución de responsabilidades explica buena parte de su eficiencia, pero también por qué es necesario conocer qué gestiona cada parte.
El modelo no es una moda pasajera ni un atajo de dudosa calidad. Permite a muchas organizaciones incorporar capacidades sin construirlas desde cero. Precisamente por su valor, merece un proceso de evaluación proporcionado y claro.
La demostración comercial muestra el producto, no todo el servicio
Una interfaz bien resuelta, un onboarding sencillo y una experiencia intuitiva son atributos valiosos. Pero una demostración suele concentrarse en lo que el usuario ve. La organización también necesita evaluar lo que ocurre detrás: quién administra el acceso a la información, qué copias existen, cómo se gestiona un incidente, qué proveedores adicionales intervienen y cómo se recuperan los datos.
La decisión no debería convertirse en una auditoría interminable para una aplicación de bajo riesgo. La profundidad del análisis debe crecer con la sensibilidad de los datos, el impacto de una interrupción y el grado de dependencia que genera el servicio.
La pregunta central: ¿qué información estamos confiando?
No todos los SaaS presentan el mismo riesgo. Una aplicación que organiza reuniones públicas no requiere las mismas garantías que otra que procesa datos personales, documentos financieros o condiciones comerciales confidenciales.
Antes de revisar certificados o arquitectura, conviene clasificar la información: ¿qué datos entran?, ¿quién los utiliza?, ¿qué consecuencias tendría una exposición, pérdida o indisponibilidad? Esa respuesta determina los controles razonables.
Siete dimensiones que conviene revisar antes de contratar
- Datos y privacidad. Solicita claridad sobre ubicación, subprocesadores, finalidades de tratamiento, plazos de conservación, eliminación y mecanismos de exportación.
- Seguridad verificable. Pregunta por cifrado, gestión de vulnerabilidades, pruebas, registros de actividad y evidencias independientes. ISO 27001, SOC 2 u otros informes pueden ayudar, pero importa su alcance y vigencia; no son garantías absolutas.
- Identidades y permisos. Revisa autenticación multifactor, inicio de sesión corporativo, perfiles, segregación de funciones y baja de usuarios.
- Continuidad. Comprueba compromisos de disponibilidad, copias de seguridad, recuperación, soporte e información ante incidentes.
- Salida y portabilidad. Asegura que la información pueda recuperarse en formatos utilizables y que el contrato defina tiempos, costes y borrado posterior.
- Integraciones. Comprende qué APIs y conectores se utilizarán, con qué permisos y cómo se registran los intercambios con otros sistemas.
- Responsabilidad contractual. Identifica la entidad que presta el servicio, condiciones aplicables, responsabilidades, tratamiento de datos y procedimientos de escalamiento.
La certificación es evidencia, no un sustituto del criterio
Los estándares y cuestionarios pueden facilitar una evaluación comparable. La Cloud Security Alliance mantiene CAIQ, un cuestionario para transparentar controles cloud, y un registro STAR con diferentes niveles de aseguramiento. Es una herramienta útil para iniciar preguntas, no una puntuación mágica que determine si un proveedor es seguro.
Una empresa joven puede gestionar bien sus riesgos sin contar todavía con todas las acreditaciones. Una empresa grande puede presentar informes sólidos y aun así no cumplir los requisitos concretos de un cliente. Lo importante es solicitar evidencia adecuada al servicio y entender sus límites.
También debemos gobernar lo que ocurre después de contratar
La evaluación inicial no termina el trabajo. Los permisos cambian, aparecen nuevas integraciones, se incorporan usuarios y evolucionan las condiciones del servicio. Por eso conviene definir quién es el dueño del SaaS dentro de la organización, qué métricas revisa y cuándo debe revalidarse el riesgo.
La adopción descentralizada no es necesariamente mala, pero sí puede volver invisibles las dependencias si cada área contrata por su cuenta sin inventario ni políticas comunes.
Una decisión informada es una decisión más rápida a largo plazo
No necesitamos convertir cada compra en un proyecto de seis meses. Necesitamos una lista de preguntas clara, escalable y proporcional al riesgo. La facilidad de adopción del SaaS debe ser una ventaja competitiva, no una excusa para renunciar al gobierno.
Guarda esta guía para la próxima evaluación. Lo relevante no es si el proveedor tiene una marca conocida, sino si puede demostrar que la solución cumple las necesidades, los controles y las obligaciones de tu organización.