La web de cualquier proveedor de ciberseguridad dirá que su producto es «de nivel empresarial» y que «lo utilizan compañías líderes en todo el mundo». Nada de eso te cuenta qué ocurre a las 02:00 cuando su plataforma no detecta una intrusión, ni cuántas horas pasan hasta que alguien te avisa. Evaluar a un proveedor de seguridad no se parece a evaluar una herramienta de gestión de proyectos: todo el trabajo del producto consiste en reducir tu riesgo, así que una cláusula floja aquí no es una simple molestia, se convierte en el riesgo. Este es el checklist que conviene pasar en compras, TI y jurídico antes de firmar cualquier contrato de ciberseguridad.
Por qué no basta con un checklist genérico de proveedores
Un checklist de compras genérico cubre siempre las mismas cuatro casillas: precio, disponibilidad, nivel de soporte y esfuerzo de integración. Con un proveedor de seguridad todo eso sigue importando, pero no basta: estas herramientas reciben accesos privilegiados como la ingesta de logs, sondas de red, agentes de endpoint con permisos a nivel de kernel o acceso de lectura a tu proveedor de identidad. La evaluación necesita una capa más: qué está certificado a proteger el proveedor en realidad, con qué rapidez detecta y responde, qué pasa con tus datos cuando acaba el contrato y quién responde si la herramienta falla justo en el momento que importa.
1. Certificaciones: qué demuestran de verdad SOC 2 e ISO 27001
Que un proveedor escriba «cumple SOC 2» en una presentación comercial no es lo mismo que entregarte un informe SOC 2 Tipo II vigente. Hay tres distinciones que importan:
- Tipo I frente a Tipo II. El Tipo I acredita que los controles existían en una fecha concreta; el Tipo II, que funcionaron de forma efectiva durante un periodo de 6 a 12 meses. Pide siempre el Tipo II.
- Antigüedad del informe. Por convención, más de 12 meses es un informe caducado. Pide el ciclo vigente y apunta tú mismo la fecha de renovación en el calendario.
- El alcance, no solo el logotipo. Ambos marcos certifican un alcance definido, recogido en la Declaración de Aplicabilidad de ISO o en la descripción del sistema de SOC 2. Un proveedor puede estar certificado para una línea de producto mientras el módulo que vas a contratar queda fuera del perímetro auditado.
Si en tu equipo nadie está acostumbrado a leer estos informes, la guía de la AICPA sobre SOC 2 es una buena referencia de partida.
2. Qué mirar en el SLA más allá del porcentaje de disponibilidad
El porcentaje de disponibilidad es el dato más fácil de comparar y el menos informativo en una herramienta de seguridad. Lo que de verdad cuenta en el SLA (acuerdo de nivel de servicio) es otra cosa:
- Latencia de detección. El tiempo que pasa entre el evento y la alerta. Una herramienta «operativa» que tarda seis horas en sacar a la luz una alerta crítica no te está protegiendo.
- MTTA y MTTR del propio servicio de soporte del proveedor. Un ticket P1 sin acuse de recibo durante cuatro horas es el número que debería preocuparte.
- Cadencia de la inteligencia de amenazas. ¿Cada cuánto se actualiza el conjunto de reglas frente a los nuevos CVE? Quien no sabe responder con precisión suele actualizar de forma reactiva.
- Mecánica de los créditos. La mayoría de los SLA de seguridad limitan los créditos a entre un 10 % y un 25 % de la cuota mensual: lee qué cubre en realidad ese tope.
La mecánica general para comparar el clausulado de un SLA entre proveedores (ventanas de medición, exclusiones, vías de escalado) está en nuestro checklist de comparación de SLA; aquí se aplican los mismos criterios, sumando los tiempos de detección y de respuesta.
3. Compromisos de respuesta ante incidentes que conviene dejar por escrito
Es la sección que el contrato marco (MSA) de la mayoría de los proveedores deja en vago, y también la que más pesa. Insiste en compromisos concretos y numerados:
- Plazo de notificación de brechas. ¿Cuántas horas tiene el proveedor para avisarte desde que detecta el incidente? «Esfuerzos comercialmente razonables» no es una cifra: exige un plazo firme de 24 a 48 horas.
- Informe posterior al incidente. Análisis de causa raíz por escrito, medidas correctoras y calendario, entregado en un número definido de días hábiles. Un repaso verbal no vale.
- Derecho de auditoría. Derecho anual a recibir el informe SOC 2 o ISO 27001 vigente y un resumen del último test de intrusión, sin tener que renegociarlo cada vez.
- Aviso de subencargados y de requerimientos judiciales. Preaviso antes de incorporar a un subencargado del tratamiento y aviso de cualquier requerimiento que afecte a tus datos, siempre que la ley lo permita.
En el ámbito financiero y de las infraestructuras críticas de la UE estas cláusulas no son opcionales: el Reglamento DORA (Reglamento (UE) 2022/2554) impone plazos concretos de notificación de incidentes relacionados con las TIC que los contratos con proveedores deben reflejar. Nuestro checklist de compras para DORA y NIS2 detalla lo que los supervisores esperan encontrar en el propio contrato.
4. Tratamiento de datos y cláusulas de subencargados
Las herramientas de seguridad recogen más telemetría que cualquier otro proveedor de tu stack: registros, metadatos de paquetes, actividad en el endpoint y, a veces, credenciales. Confirma por escrito cuatro puntos:
- Ubicación de los datos — dónde se almacenan la telemetría y los registros, y si puede restringirse a una región concreta.
- Detalles del cifrado — algoritmo y longitud de clave en reposo y en tránsito, y si se ofrecen claves gestionadas por el cliente.
- Conservación y borrado — un plazo contractual de borrado tras la finalización del contrato. Treinta días naturales es razonable; «a nuestra discreción» no lo es.
- Lista de subencargados — una relación actualizada de quién más toca tus datos, con el estado de certificación de cada uno.
El contrato marco estándar de la mayoría de los proveedores responde a algunas de estas cuestiones y guarda silencio sobre el resto. En lugar de enviar a cada finalista el cuestionario SIG o CAIQ completo, con sus más de cien preguntas, sale mucho más a cuenta generar una lista corta apuntada a lo que su contrato no cubre. Esa es la lógica de nuestro generador de cuestionarios SIG, CAIQ y SOC 2, que saca a la superficie solo los huecos reales.
Preguntas de la RFP para enviar a los finalistas
Diez preguntas que consiguen respuestas reales en lugar de material de marketing:
- Facilitar el informe SOC 2 Tipo II más reciente, con indicación del periodo auditado y del alcance definido.
- Indicar el plazo comprometido de notificación de brechas, en horas desde la detección.
- Indicar los valores contractuales de MTTA y MTTR para los tickets de soporte P1.
- Confirmar si se ofrecen claves de cifrado gestionadas por el cliente y en qué plan.
- Especificar el plazo de borrado de datos tras la finalización del contrato, como cláusula del contrato.
- Enumerar todos los subencargados con acceso a datos y el procedimiento de aviso cuando se incorpore uno nuevo.
- Indicar con qué frecuencia se actualiza el conjunto de reglas de detección frente a los CVE recién publicados.
- Especificar el crédito máximo previsto en el SLA y qué supuestos excluyen una reclamación.
- Compartir un resumen del último test de intrusión.
- Concretar el compromiso de ubicación de los datos y si puede restringirse a una región.
¿Dónde se esconden las señales de alerta en la ronda final?
Cuando llegas a comparar las ofertas de los finalistas, el riesgo rara vez es una certificación que falta: es un texto que parece correcto de pasada y se cae al leerlo con calma. «Esfuerzos comercialmente razonables para notificar» en lugar de un número firme de horas. Una declaración de alcance de SOC 2 que deja fuera, sin hacer ruido, el módulo que estás comprando. Una cláusula de subencargados sin obligación de preaviso. Son exactamente los patrones que la detección automática de señales de alerta está pensada para cazar: analiza el contrato marco y los anexos de SLA que subes, localiza plazos de respuesta sin definir y huecos de alcance, y marca cada hallazgo por gravedad con la cláusula literal citada al lado, para que nada se quede enterrado en la página 40 de un documento de 70.
Y si tu equipo tiene innegociables — un SOC 2 Tipo II de menos de 12 meses, una ventana de notificación de 24 horas, una región concreta de alojamiento de datos — dejarlos escritos una sola vez como posiciones exigidas hace que todos los finalistas se contrasten automáticamente con el mismo listón.
Resumen en una página
- SOC 2 Tipo II con fecha dentro de los últimos 12 meses y alcance verificado frente al producto que se contrata
- Declaración de Aplicabilidad de ISO 27001 revisada, no solo el certificado
- Latencia de detección y MTTA/MTTR por escrito, no solo el porcentaje de disponibilidad
- Plazo de notificación de brechas como número firme de horas, no «esfuerzos comercialmente razonables»
- Informe posterior al incidente por escrito, con fecha de entrega definida
- Derecho anual de auditoría y a los resúmenes de los test de intrusión
- Lista de subencargados con preaviso antes de cualquier cambio
- Ubicación de los datos, detalles del cifrado y plazo de borrado tras la finalización
- Tope de créditos y procedimiento de reclamación recogidos por escrito