Playbook: evaluación exprés de un proveedor SaaS (checklist + puntuación en 60 minutos)

Cada nuevo proveedor SaaS introduce algo más que una licencia de software. Introduce dependencia operativa, exposición de datos, nuevas integraciones, cambios potenciales en la forma de trabajar y, en muchos casos, una obligación implícita de responder cuando algo falla. Por eso, una evaluación de terceros útil no debe redactarse como un ejercicio puramente técnico, sino como una decisión de negocio con consecuencias prácticas.

En términos de negocio, la pregunta central no es si el proveedor “parece serio”, sino qué ocurrirá si el servicio cae, si la respuesta ante un incidente es lenta, si hay que extraer los datos para cambiar de plataforma o si se descubre demasiado tarde que el proveedor depende de otros terceros sobre los que nadie tenía visibilidad. Cuando esto no se evalúa antes, el coste suele aparecer después en forma de retrasos operativos, reprocesos, conflictos contractuales, urgencias con legal, dependencia comercial y desgaste interno entre compras, TI, seguridad y el área usuaria.

Un marco exprés bien diseñado reduce precisamente ese problema. Permite que compras y negocio avancen con rapidez en herramientas de baja criticidad, mientras reserva más profundidad para los servicios que afectan procesos esenciales, manejan datos sensibles o concentran permisos relevantes. Eso evita dos extremos igual de dañinos: convertir cualquier compra de software en una mini auditoría interminable o aprobar herramientas críticas sin una base mínima de control.

También tiene un impacto directo en la calidad de decisión. Si dos proveedores similares se evalúan con criterios diferentes según quién esté disponible o quién presione más, la organización no solo pierde consistencia: pierde capacidad de defender por qué aceptó un riesgo y no otro. Un modelo simple y trazable mejora esa consistencia porque obliga a responder las mismas preguntas clave, asignar una puntuación comparable y dejar por escrito las excepciones.

En la práctica, esto significa cinco cosas para negocio:

• que la velocidad de compra puede mantenerse si el nivel de exigencia se adapta a la criticidad real;
• que los riesgos más costosos suelen ser de continuidad, dependencia y salida, no solo de cumplimiento;
• que un buen proceso de evaluación reduce discusiones subjetivas entre áreas;
• que las excepciones deben tener responsable, plazo y condiciones;
• y que la trazabilidad interna es tan importante como la revisión inicial.

Este playbook está pensado para cubrir ese espacio: una decisión útil en una hora, suficientemente rigurosa para sostenerse ante auditoría interna y suficientemente ligera para no bloquear la operación.

Acciones recomendadas

1. Clasifica cada proveedor SaaS en nivel 1, 2 o 3 antes de pedir documentos o lanzar la negociación final.
2. Usa un checklist base común para todos y solicita evidencias adicionales solo cuando la criticidad lo justifique.
3. Aplica una hoja de scoring de 10 ítems con una escala de 0 a 2 y umbrales de decisión inequívocos.
4. Define de antemano quién puede aprobar excepciones, en qué casos se escala y cuándo debe rechazarse o pausarse la contratación.
5. Incorpora cláusulas de negocio comprensibles sobre incidentes, soporte en crisis, subprocesadores, continuidad y salida ordenada.
6. Guarda una traza mínima de decisión en un registro interno único y revisable por compras, riesgo, cumplimiento o auditoría interna.
7. Reevalúa al proveedor cuando cambie el uso, la criticidad, los datos tratados, las integraciones o las condiciones del servicio.

El método de 60 minutos: criticidad + checklist + scoring + umbrales

El objetivo de este playbook es llegar a una decisión útil en torno a 60 minutos, sin inventar complejidad innecesaria. Para lograrlo, el proceso debe ser secuencial y disciplinado. No conviene empezar por un cuestionario interminable ni por una discusión abstracta sobre controles ideales. Conviene seguir cuatro pasos:

1. clasificar criticidad;
2. revisar checklist mínimo;
3. puntuar 10 ítems;
4. decidir con umbrales claros y registrar la resolución.

Una distribución razonable del tiempo sería esta:

• 10 minutos para clasificar la criticidad;
• 20 minutos para completar el checklist mínimo y revisar evidencias esenciales;
• 15 minutos para puntuar;
• 15 minutos para decidir, fijar condiciones si aplica y registrar la traza.

Si en ese tiempo no puede completarse la revisión porque faltan elementos básicos, eso ya es una señal de riesgo operativo o de mala preparación del caso. El objetivo no es forzar un sí, sino hacer visible si hay base suficiente para decidir.

Paso 1: clasificar criticidad antes de pedir evidencias

La primera decisión debe ser el nivel de criticidad. Sin esa clasificación, el proceso suele volverse ineficiente: se pide demasiado a proveedores de impacto limitado y demasiado poco a los realmente sensibles.

Nivel 1: baja criticidad

Clasifica el proveedor como nivel 1 cuando el servicio:

• no soporta un proceso crítico;
• no concentra datos sensibles o de alto valor;
• tiene un número acotado de usuarios;
• y una caída temporal puede gestionarse con molestias limitadas o trabajo manual asumible.

En este nivel, el error más común es sobredimensionar la revisión y retrasar una compra de bajo impacto.

Nivel 2: criticidad media

Clasifica como nivel 2 cuando el servicio:

• apoya un proceso relevante para varias áreas;
• trata datos de negocio con impacto moderado;
• tiene alguna integración con sistemas internos;
• o su indisponibilidad afectaría productividad, calidad de servicio o tiempos de respuesta durante varias horas o días.

Aquí ya no basta con confiar en respuestas genéricas. Debe existir una base razonable de control y operación.

Nivel 3: alta criticidad

Clasifica como nivel 3 cuando el servicio:

• soporta procesos esenciales;
• trata datos sensibles, regulados o especialmente valiosos;
• dispone de privilegios elevados o integración profunda;
• o una caída afectaría ingresos, cumplimiento, atención al cliente o continuidad.

En este nivel, el proceso no debe convertirse en auditoría infinita, pero sí debe exigir evidencias más sólidas y compromisos más claros.

Tres preguntas para decidir rápido

Para clasificar sin ambigüedad, responde estas preguntas:

1. Datos: ¿qué datos ve, aloja o procesa el proveedor?
2. Proceso: ¿qué parte del negocio depende realmente de este SaaS?
3. Impacto: si mañana deja de funcionar durante 24 a 72 horas, ¿qué se detiene, degrada o expone?

Si una sola respuesta apunta a impacto alto, lo prudente es tratarlo como nivel 3 hasta aclararlo mejor.

Paso 2: checklist mínimo, sin auditoría infinita

Una evaluación exprés funciona solo si distingue entre preguntas obligatorias y evidencias opcionales según criticidad. El principio es simple: todos los proveedores responden un mínimo común, pero no todos tienen que demostrar lo mismo.

Checklist base para todos los niveles

Estas preguntas deben cubrirse siempre, incluso en SaaS de baja criticidad:

1. Qué datos trata o puede visualizar.
2. Qué usuarios internos tendrán acceso y con qué perfiles.
3. Cómo se gestionan altas y bajas de usuarios.
4. Qué soporte ofrece si el servicio falla.
5. Si existe una forma definida de recuperación o restauración.
6. Si notifica incidentes relevantes.
7. Si utiliza subprocesadores o terceros para prestar el servicio.
8. Dónde se alojan o procesan los datos.
9. Qué opciones de salida o exportación existen.
10. Qué condiciones contractuales o de servicio aplican.

Este checklist no pretende agotar todos los controles posibles. Pretende validar si existe una base mínima para contratar con criterio.

Evidencias mínimas por nivel

Nivel 1: lo esencial y nada más

Para un SaaS de baja criticidad, bastará normalmente con:

• descripción funcional del servicio;
• condiciones de servicio o contrato estándar;
• información básica de soporte;
• respuesta escrita al checklist;
• confirmación simple sobre datos, ubicación y salida.

La decisión en este nivel no necesita una colección documental extensa. Si el impacto es bajo, pedir más de forma sistemática genera fricción sin mejorar de verdad la gestión del riesgo.

Nivel 2: información operativa suficiente

Para criticidad media, conviene pedir además:

• explicación de roles y permisos;
• resumen de continuidad o recuperación;
• forma de notificación de incidentes;
• información sobre subprocesadores;
• ubicación de datos más definida;
• detalle básico de SLA o canales de soporte.

La clave aquí es la consistencia: no hace falta un paquete exhaustivo, pero sí respuestas utilizables y no puramente comerciales.

Nivel 3: más claridad, no burocracia vacía

Para criticidad alta, deberían revisarse además:

• evidencias documentadas sobre accesos y privilegios;
• compromiso contractual de notificación de incidentes;
• detalle operativo de continuidad y restauración;
• modelo de soporte en crisis y escalado;
• control de subprocesadores y cambios relevantes;
• condiciones de salida y exportación de datos.

La diferencia no está en pedir “todo”, sino en no aceptar vaguedades en aquello que sería más costoso durante una crisis.

Paso 3: scoring simple de 10 ítems

Una vez clasificada la criticidad y revisadas las evidencias mínimas, se puntúa el proveedor. El objetivo del scoring no es automatizar por completo la decisión, sino reducir subjetividad y facilitar comparabilidad entre casos.

Usa esta escala para cada ítem:

• 0 puntos: no existe información, no responde o la respuesta es claramente insuficiente;
• 1 punto: existe parcialmente, con ambigüedad, sin detalle o sin respaldo claro;
• 2 puntos: existe de forma clara, utilizable y coherente con el uso previsto.

Puntuación máxima: 20 puntos.

Hoja de puntuación

Cómo interpretar bien la puntuación

No todos los ítems pesan igual en todos los escenarios, pero hay varios que no pueden relativizarse cuando el proveedor es de nivel 2 o 3: accesos, continuidad, notificación de incidentes y salida. Un total alto no compensa un vacío grave en un punto crítico para el uso real del servicio.

Por eso el scoring debe leerse con dos lentes a la vez:

• la suma total;
• y la existencia de “ceros” en ítems sensibles.

Paso 4: umbrales de decisión inequívocos

Para que el proceso sea útil, debe terminar siempre en una de estas cuatro salidas: aprobar, aprobar con condiciones, escalar o rechazar/pausar. No conviene dejar categorías grises del tipo “pendiente de ver” sin responsable ni plazo.

1. Aprobación directa

Se puede aprobar directamente cuando se cumplan estas dos condiciones:

• 16 a 20 puntos, y
• ningún 0 en accesos, continuidad, incidentes o salida si el proveedor es nivel 2 o 3.

Quién aprueba: el responsable del área solicitante junto con compras o gestión de proveedores, siempre que no exista una excepción material.

Qué implica: contratación o renovación puede avanzar sin medidas extraordinarias, dejando registrada la decisión y la próxima revisión.

2. Aprobación con condiciones

Se encuadra aquí cualquier caso con:

• 11 a 15 puntos, o
• una puntuación superior con vacíos corregibles que no bloquean el uso si se imponen límites.

Quién aprueba: el responsable del área solicitante no debería aprobar solo. Debe validarlo también el responsable de riesgo, seguridad, cumplimiento o la función equivalente definida por la organización.

Condiciones típicas:

• limitar los datos que se cargarán en la plataforma;
• restringir perfiles o número de usuarios;
• impedir integraciones hasta cerrar acciones;
• exigir un anexo o compromiso contractual adicional;
• fijar una revisión en 30, 60 o 90 días;
• aceptar un uso transitorio mientras se corrigen vacíos.

Una aprobación con condiciones sin fecha, sin responsable y sin seguimiento equivale en la práctica a aprobar sin control.

3. Escalado obligatorio

Debe escalarse cuando ocurra cualquiera de estas situaciones:

• 6 a 10 puntos;
• un 0 en accesos, continuidad, incidentes o subprocesadores en nivel 2 o 3;
• información contradictoria sobre datos, ubicación o soporte;
• desacuerdo relevante entre el área usuaria y la función de control.

A quién se escala: como mínimo a TI o seguridad, cumplimiento o legal y al responsable del proceso afectado. Si el impacto es alto, también al comité de riesgo, comité de compras o la instancia equivalente.

Qué se decide en el escalado:

• si el proveedor puede aprobarse con restricciones excepcionales;
• si debe renegociarse alguna cláusula;
• o si debe pausarse hasta que aporte evidencias suficientes.

4. Rechazo o pausa

Debe rechazarse o pausarse la contratación cuando ocurra alguno de estos supuestos:

• 0 a 5 puntos;
• ausencia de información mínima para clasificar criticidad;
• falta de respuesta sobre datos, continuidad o acceso en un proveedor nivel 3;
• negativa a aceptar condiciones esenciales de negocio;
• imposibilidad de definir una salida razonable en un servicio crítico.

Quién formaliza el rechazo o la pausa: compras o gestión de proveedores junto con la función de control designada, dejando constancia de la causa y de qué tendría que cambiar para reabrir el caso.

La diferencia entre rechazo y pausa es práctica: se rechaza cuando el proveedor no encaja o no quiere corregir, y se pausa cuando podría reabrirse si entrega información o acepta condiciones.

Circuito de escalado y aprobación de excepciones

Una de las partes más débiles en muchos procesos no es la evaluación, sino la excepción. El riesgo aparece cuando todos entienden que faltan elementos, pero nadie sabe quién tiene autoridad para asumirlo.

Un circuito simple y claro puede ser este:

• Área solicitante: explica uso, datos, impacto y urgencia.
• Compras o gestión de proveedores: coordina documentación, scoring y registro.
• TI/seguridad: revisa cuestiones de accesos, integración, continuidad y soporte si el caso lo requiere.
• Cumplimiento o legal: revisa compromisos contractuales, subprocesadores, ubicación de datos y cláusulas de salida cuando proceda.
• Responsable del proceso: confirma impacto operativo real.
• Comité o dirección designada: aprueba excepciones de alto impacto o desacuerdo entre áreas.

Regla práctica para excepciones

Una excepción solo debería aprobarse si quedan por escrito cuatro cosas:

1. qué riesgo concreto se acepta;
2. por qué se acepta ahora;
3. qué límites o controles compensatorios se imponen;
4. cuándo se revisará o cerrará la excepción.

Sin esos cuatro elementos, no hay excepción gestionada; hay simplemente una decisión poco trazable.

Cláusulas mínimas en lenguaje de negocio

El valor de una cláusula no está en sonar sofisticada, sino en ser entendible y activable cuando aparece un problema. Para un proveedor SaaS, especialmente si es nivel 2 o 3, conviene cubrir al menos estas cinco áreas.

1. Notificación de incidentes

Debe quedar claro que el proveedor notificará incidentes relevantes que afecten a la disponibilidad del servicio, a la integridad de la información o a la confidencialidad de los datos.

En lenguaje de negocio, la pregunta no es jurídica sino operativa: qué incidentes notificará, a qué contacto interno y en qué plazo operativo.

2. Soporte en crisis

No basta con un correo genérico de soporte. Debe poder saberse:

• cómo se activa una incidencia grave;
• qué canal se usa;
• quién responde;
• cómo escala internamente el proveedor;
• y qué atención recibe un evento crítico.

3. Subprocesadores

El cliente necesita una visibilidad razonable sobre terceros que participan en la prestación del servicio, sobre todo si su papel afecta datos, disponibilidad o soporte. No se trata de revisar toda la cadena de valor, sino de evitar dependencias invisibles.

4. Continuidad del servicio

La organización debe entender, al menos a nivel práctico, si el proveedor dispone de una forma definida de recuperación y cómo gestiona una interrupción significativa. La cláusula debe ayudar a responder qué pasará si el servicio cae y cómo se gestionará la vuelta a la normalidad.

5. Salida ordenada

Toda contratación debería contemplar la salida, no solo la entrada. Debe aclararse:

• cómo se exportan los datos;
• en qué formato;
• durante cuánto tiempo estarán disponibles tras la baja;
• y si existe soporte mínimo para la transición en los servicios críticos.

Traza mínima de decisión para auditoría interna

Un proceso rápido no está reñido con la trazabilidad. De hecho, si la evaluación va a durar 60 minutos, el registro posterior debe ser aún más disciplinado. La organización necesita poder responder, semanas o meses después, qué se evaluó, quién lo aprobó y bajo qué condiciones.

Qué se debe guardar

Como mínimo, conviene conservar:

• nombre del proveedor y del servicio;
• área solicitante;
• responsable interno del proceso;
• fecha de evaluación;
• nivel de criticidad asignado;
• checklist respondido;
• evidencias revisadas;
• puntuación final;
• decisión adoptada;
• condiciones o excepciones, si las hay;
• aprobadores;
• fecha de próxima revisión.

Dónde guardarlo

Debe guardarse en un registro interno único y accesible para las funciones que lo necesiten: compras, gestión de proveedores, riesgo, cumplimiento, seguridad o auditoría interna. Puede ser una herramienta de compras, un repositorio documental controlado, un GRC o un registro compartido con gobierno claro. Lo importante no es la herramienta perfecta, sino que exista una ubicación oficial, consistente y revisable.

Qué formato mínimo sirve

Si la organización todavía no tiene una plataforma específica, basta con una ficha estándar por proveedor y un registro maestro con estos campos:

Con eso ya existe una traza defensible para auditoría interna y para futuras renovaciones.

Errores comunes que este playbook evita

Aunque el proceso parezca sencillo, suele romperse por patrones repetidos.

Pedir demasiado pronto

Un error muy frecuente es lanzar listas de requerimientos extensas antes de saber si el proveedor es crítico o no. Resultado: se ralentiza una compra menor y el área usuaria intenta saltarse el proceso.

Confiar en respuestas comerciales genéricas

Otro error es aceptar frases del tipo “tenemos las mejores prácticas” sin aclarar cómo se traducen en acceso, continuidad, soporte o salida. En baja criticidad esto puede ser suficiente en parte; en alta criticidad no.

Aprobar con condiciones que nadie sigue

Si no hay responsable ni fecha de cierre, la condición no se ejecuta. Y si no se ejecuta, el riesgo sigue donde estaba.

No decidir quién aprueba la excepción

Cuando esto no está prefijado, la excepción se convierte en una negociación informal entre áreas. Eso genera frustración y una trazabilidad muy débil.

Olvidar la salida

Muchas evaluaciones se concentran en entrar rápido y dejan para después la portabilidad. Ese “después” suele llegar en el peor momento: subida de precios, deterioro del servicio, cambio estratégico o incidencia grave.

Plantilla práctica para usar en 60 minutos

A continuación, una plantilla compacta para aplicar el playbook.

Ficha de evaluación exprés

Proveedor / servicio: Área solicitante: Responsable interno: Fecha: Nivel de criticidad propuesto: Nivel 1 / Nivel 2 / Nivel 3

A. Datos, proceso e impacto

• ¿Qué datos trata o puede ver?
• ¿Qué proceso de negocio soporta?
• Si falla 24–72 horas, ¿qué ocurre?
• ¿Qué usuarios tendrán acceso?
• ¿Existe integración con otros sistemas?

B. Checklist mínimo

Marca: Sí / Parcial / No

• Datos clasificados
• Accesos y permisos definidos
• Altas y bajas de usuarios
• Continuidad del servicio
• Backup o recuperación
• Notificación de incidentes
• Subprocesadores
• Ubicación de datos
• SLA o soporte
• Salida o exportación

C. Evidencias revisadas

• Contrato o condiciones
• Respuesta al cuestionario
• Resumen de soporte
• Resumen de continuidad
• Anexos o compromisos adicionales

D. Scoring

E. Decisión

• 16–20 y sin ceros críticos en nivel 2–3: Aprobar
• 11–15: Aprobar con condiciones
• 6–10 o ceros críticos: Escalar
• 0–5 o falta de base mínima: Rechazar o pausar

Aprobadores: Condiciones o excepciones: Fecha de revisión: Ubicación del expediente interno:

Cierre

Evaluar un proveedor SaaS en 60 minutos es posible si la organización acepta una idea simple: rapidez no significa superficialidad y control no significa burocracia. Lo que hace útil a este playbook no es la cantidad de preguntas, sino la secuencia correcta: clasificar criticidad, revisar lo mínimo necesario, puntuar con criterios consistentes y decidir con umbrales claros.

El beneficio real no está solo en aprobar mejor. Está en discutir menos de forma improductiva, escalar solo cuando corresponde, exigir cláusulas comprensibles y mantener una traza de decisión que permita defender por qué se contrató, bajo qué condiciones y con qué plan de revisión.

Si se aplica con disciplina, este marco evita la auditoría infinita para SaaS no crítico y, al mismo tiempo, eleva el nivel de exigencia donde más importa: continuidad, accesos, incidentes, dependencia y salida. Ahí es donde un proceso de evaluación deja de ser un trámite y empieza a proteger de verdad al negocio.