Cómo evaluar la seguridad de un proveedor SaaS

Cada vez que una empresa contrata un servicio SaaS —software como servicio, por sus siglas en inglés— está tomando una decisión de seguridad sin necesariamente saberlo. Al usar un CRM en la nube, una plataforma de facturación, una herramienta de gestión de proyectos o un servicio de correo empresarial, la empresa está depositando sus datos en servidores que no controla, operados por un proveedor al que no conoce en profundidad y sujeto a prácticas de seguridad que no puede verificar directamente.

La decisión de negocio —"esta herramienta resuelve lo que necesitamos a un precio razonable"— suele tomarse antes y sin conexión con la decisión de seguridad —"¿este proveedor va a proteger nuestros datos tan bien como lo haríamos nosotros?"—. El resultado es que empresas que nunca delegarían el control de su información financiera o de sus clientes terminan haciéndolo sin darse cuenta, porque el SaaS no se presenta como una delegación sino como una herramienta.

Este artículo propone un método para evaluar la seguridad de un proveedor SaaS antes de contratar, usando criterios que cualquier persona puede aplicar sin conocimientos técnicos especializados.

Lo que está en juego cuando se contrata un SaaS

Para dimensionar el riesgo, conviene hacerse una pregunta simple: ¿qué pasaría si mañana todos los datos que están en ese SaaS se hicieran públicos, se perdieran o quedaran inaccesibles durante una semana?

Si la respuesta es "nada grave", el riesgo es bajo y la evaluación de seguridad puede ser proporcionalmente ligera. Pero en la mayoría de los casos, la respuesta incluye consecuencias como:

• Datos de clientes expuestos, con el consiguiente daño legal y reputacional.
• Incapacidad de facturar, cobrar o registrar operaciones mientras el servicio está caído.
• Pérdida irrecuperable de información si el proveedor no tiene respaldos adecuados o si la empresa no tiene copias propias de sus datos.
• Dependencia de un proveedor que, si cambia sus condiciones, deja a la empresa sin margen de negociación porque migrar los datos a otro sistema es complejo y costoso.

El artículo sobre qué es una brecha de seguridad y cómo puede afectar a una empresa detalla estas consecuencias. Cuando el origen de la brecha es un proveedor y no un sistema propio, la empresa sigue siendo responsable frente a sus clientes —el proveedor no va a llamar a los clientes de la empresa a pedir disculpas—, pero tiene menos control sobre la causa y la solución.

Las cinco preguntas que todo proveedor SaaS debería poder responder

No hace falta ser experto en seguridad para evaluar a un proveedor. Alcanza con hacer las preguntas correctas y prestar atención a cómo las responden. Un proveedor que toma la seguridad en serio responde con precisión y sin evasivas. Un proveedor que no, responde con generalidades o con lenguaje técnico que no aclara nada.

1. ¿Dónde se almacenan los datos y quién tiene acceso?

La ubicación geográfica de los datos importa por dos razones. La primera es regulatoria: muchos países exigen que ciertos tipos de datos —especialmente datos personales y financieros— no salgan del país o de la región sin protecciones específicas. La segunda es práctica: si los datos están en un país con legislación laxa, la empresa tiene menos herramientas legales para reclamar si algo sale mal.

Un proveedor serio puede decir exactamente en qué país o región están sus servidores. Si la respuesta es "en la nube" sin más precisión, o si el proveedor no sabe responder, es una señal de alerta.

Respecto a quién tiene acceso, la respuesta esperable es que el acceso está restringido a personal autorizado mediante autenticación robusta, que se registra cada acceso, y que el acceso del personal del proveedor a los datos de los clientes es limitado y auditado. Si el proveedor dice que "solo los administradores" pueden acceder sin explicar cuántos son, quiénes son y bajo qué circunstancias acceden, la respuesta es insuficiente.

2. ¿Los datos están cifrados?

El cifrado es la práctica de convertir la información en un formato ilegible para cualquiera que no tenga la clave para descifrarla. Un proveedor SaaS debería cifrar los datos en dos momentos:

• En tránsito: cuando los datos viajan entre el dispositivo del usuario y los servidores del proveedor. Esto se verifica observando que la URL del servicio comience con "https://" y que el navegador muestre el candado de conexión segura.
• En reposo: cuando los datos están almacenados en los servidores del proveedor. Esto no es visible para el usuario; el proveedor tiene que declararlo explícitamente. Si un atacante obtiene acceso físico a los discos del proveedor, los datos cifrados son inútiles sin la clave de descifrado.

Un proveedor que no cifra los datos en reposo está operando con un estándar de seguridad inferior al esperable en 2026. Si además no puede explicar quién maneja las claves de cifrado —idealmente, el cliente debería tener control sobre sus propias claves—, el riesgo es mayor.

3. ¿Qué pasa con los datos si cancelo el servicio?

Esta pregunta evalúa dos cosas: la capacidad de la empresa de irse del proveedor sin perder su información, y la política del proveedor sobre retención y eliminación de datos después de la cancelación.

Un proveedor serio debería:

• Permitir exportar los datos en un formato estándar —no en un formato propietario que solo su sistema puede leer— antes de cancelar el servicio.
• Especificar cuánto tiempo retiene los datos después de la cancelación y qué hace con ellos cuando ese plazo vence —idealmente, eliminarlos de forma definitiva—.
• Confirmar por escrito que los datos fueron eliminados, si el cliente lo solicita.

Si el proveedor no permite exportar los datos, o los exporta en un formato que ningún otro sistema puede leer sin procesamiento adicional costoso, la empresa está atrapada. Migrar a otro proveedor va a costar más de lo que cuesta quedarse, y el proveedor lo sabe.

4. ¿Cómo gestionan los respaldos y la recuperación ante desastres?

Todo proveedor SaaS debería tener respaldos. Pero no todos los respaldos son iguales. Lo que hay que preguntar:

• Frecuencia de los respaldos. ¿Cada hora, cada día, cada semana? Cuanto más frecuente, menos datos se pierden en un incidente.
• Ubicación de los respaldos. ¿Están en una ubicación geográfica distinta de los servidores principales? Si un desastre natural afecta el data center principal y los respaldos están en el mismo lugar, ambos se pierden.
• Tiempo de recuperación. Si ocurre un incidente grave, ¿cuánto tiempo pasa hasta que el servicio vuelve a estar operativo? El proveedor debería tener un objetivo de tiempo de recuperación —RTO, por sus siglas en inglés— declarado contractualmente.
• Pruebas de restauración. ¿El proveedor prueba regularmente que sus respaldos se pueden restaurar? Un respaldo que nunca se probó es una esperanza, no una certeza.

5. ¿Tienen certificaciones de seguridad o auditorías externas?

Las certificaciones no garantizan que un proveedor sea seguro, pero muestran que un tercero independiente revisó sus prácticas y las encontró conformes a un estándar definido. Las certificaciones más relevantes en el mundo SaaS:

• SOC 2: una auditoría que verifica controles de seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Es el estándar más común en proveedores SaaS serios.
• ISO 27001: una norma internacional para sistemas de gestión de seguridad de la información. Requiere que el proveedor tenga un proceso sistemático para gestionar riesgos de seguridad.
• GDPR compliance: si el proveedor opera en Europa o tiene clientes europeos, debería cumplir con el Reglamento General de Protección de Datos. Para empresas fuera de Europa, un proveedor que cumple con GDPR suele tener estándares más altos que el promedio.

Un proveedor chico o nuevo puede no tener certificaciones porque son costosas y toman tiempo obtenerlas. En ese caso, lo que hay que evaluar es si tiene prácticas equivalentes aunque no estén certificadas: ¿tiene una política de seguridad documentada? ¿Hace pruebas de penetración periódicas? ¿Tiene un procedimiento para notificar a los clientes si ocurre un incidente de seguridad?

Señales de alerta que no se deben ignorar

Hay respuestas y actitudes que, por sí solas, deberían hacer reconsiderar la contratación de un proveedor, independientemente de lo atractivo que sea su precio o su funcionalidad:

• No puede responder las preguntas anteriores. Si el vendedor no sabe dónde se almacenan los datos, si están cifrados o qué certificaciones tienen, y no puede conseguir las respuestas del equipo técnico en un plazo razonable, el proveedor no tiene la seguridad como prioridad.
• Las respuestas son evasivas o excesivamente técnicas sin traducción. "Usamos encriptación de nivel militar" no significa nada. "Usamos AES-256 para cifrado en reposo y TLS 1.3 para cifrado en tránsito" es una respuesta precisa. Si cada pregunta recibe una respuesta vaga o un término técnico sin explicación, el proveedor está evitando comprometerse.
• No tiene un canal para reportar vulnerabilidades de seguridad. Un proveedor que toma la seguridad en serio tiene un correo o un formulario específico para que investigadores o clientes reporten problemas de seguridad. Si no existe, es porque el proveedor no quiere oír hablar de vulnerabilidades.
• No tiene un historial público de incidentes ni comunicación sobre cómo los manejó. Todos los proveedores tienen incidentes en algún momento. Lo que distingue a uno serio no es la ausencia de incidentes, sino la transparencia con que los comunica y la velocidad con que los resuelve. Un proveedor que nunca tuvo un incidente —o que no los comunica— es una caja negra.

Qué hacer después de contratar

La evaluación de seguridad no termina cuando se firma el contrato. Hay tres prácticas que convierten la evaluación inicial en una postura de seguridad continua:

• Revisar la configuración de seguridad del servicio. La mayoría de los SaaS ofrecen opciones de seguridad que vienen desactivadas por defecto —autenticación en dos pasos, registro de actividad, restricciones de acceso por IP—. Activarlas toma minutos y reduce significativamente la exposición.
• Monitorear los cambios en los términos de uso y la política de privacidad. Los proveedores suelen notificar estos cambios por correo. Leerlos —o pedirle a alguien que los lea— no toma más de cinco minutos y permite detectar modificaciones que afectan la seguridad o la privacidad de los datos.
• Exportar los datos periódicamente y guardarlos en un lugar controlado por la empresa. Incluso si el proveedor tiene respaldos, tener una copia propia en un formato estándar asegura que la empresa pueda migrar a otro proveedor o reconstruir su información si el proveedor desaparece, cambia sus condiciones de manera inaceptable o sufre un incidente grave.

El artículo sobre qué preguntar sobre seguridad a tu proveedor de software complementa esta guía con preguntas específicas para proveedores de desarrollo a medida. Aunque el contexto es distinto —un desarrollo a medida versus un SaaS estandarizado—, muchos de los principios aplican a ambos: la seguridad se evalúa haciendo preguntas, no asumiendo que porque el proveedor es grande o conocido, ya se ocupó del tema.