RFP de MSSP y MDR: playbook independiente en 8 pasos

La mayoría de las selecciones de MSSP y MDR fracasan antes de escribir el RFP. El comprador parte de una lista de proveedores, asiste a demostraciones y deja que el pitch más persuasivo defina los requisitos. El resultado es un proveedor elegido por química y precio, con un alcance que refleja el catálogo del vendedor y no las brechas reales del comprador.

El mismo sesgo de optimismo que distorsiona la puntuación interna de madurez distorsiona el procurement. Los datos del informe SOC-CMM 2026 muestran que las autoevaluaciones sobrestiman la madurez en torno a 0,6 puntos en la escala 0-5. Un equipo que se cree más fuerte de lo que es compra el servicio equivocado: demasiado estrecho donde es débil, redundante donde ya es capaz. Una visión independiente y de tercero del estado actual corrige la línea base antes de mover dinero.

Este playbook establece ocho pasos. Cada uno produce un artefacto documentado: catálogo de requisitos, long-list con criterios de exclusión, scorecard, informe de prueba de valor, anexo contractual y recomendación firmada. Los reguladores que revisan decisiones sobre terceros TIC bajo DORA y NIS2 piden exactamente esta trazabilidad.

El paso 1 traduce los hallazgos del SOC-CMM en requisitos concretos de servicio. Las medias de dominio de 2026 explican por qué importa: Tecnología ronda 2,7 mientras que Servicios queda en 2,2 y Personas en 2,3. Muchas organizaciones no necesitan más tooling de un MSSP; necesitan disciplina operativa sostenida, cobertura fuera del horario laboral y entrega de servicio documentada. El perfil de madurez le dice cuál de las dos cosas necesita usted.

• Casos de uso y fuentes de log: qué escenarios de detección debe cubrir el proveedor y alimentados por qué fuentes suyas.
• Niveles de servicio expresados en términos de detección y respuesta, no solo de acuse de recibo del ticket.
• Geografía, residencia de datos e idiomas de trabajo, incluido el idioma de los informes para el consejo.
• Integraciones con su SIEM, ticketing e identidad, con la propiedad de cada interfaz declarada.
• Condiciones de salida definidas como requisito desde el primer día: handover, devolución de datos, portabilidad de runbooks.

El paso 2 construye la long-list: de 8 a 12 candidatos filtrados con criterios de exclusión explícitos, como falta de presencia en su jurisdicción, no soportar una fuente de log obligatoria o carecer de referencias verificables en su sector. Deje las exclusiones por escrito. Una long-list sin criterios documentados es lo primero que cuestionará un auditor.

Capacidad es si un elemento del servicio existe y cómo está diseñado. Madurez es con qué consistencia se ejecuta, se mide y se mejora. El SOC-CMM separa ambas dimensiones, y su cuestionario de prefiltrado (paso 3) y el RFP detallado a los 3 o 4 finalistas (paso 4) deberían hacer lo mismo. Todos los proveedores aprueban el examen de capacidad sobre el papel. Las diferencias aparecen con las preguntas de madurez.

• Muestre el cumplimiento de SLA de los últimos 12 meses para un cliente de nuestro tamaño y sector, no una media de marketing.
• ¿Con qué frecuencia se revisan los runbooks de detección, quién lo hace y dónde está el histórico de cambios?
• ¿Cuál es la rotación de analistas del último año, y tendremos un equipo nominal o un primer nivel compartido?
• ¿Cuál es la cadencia de ingeniería de detección: casos de uso nuevos y ajustados por trimestre, con ejemplos?
• Si declara cobertura ATT&CK, ¿qué técnicas exactamente y cómo se validó? Cifras autorreportadas en torno a la media del 60% dicen poco sin la lista de técnicas.
• Entregue un informe de incidente y un informe mensual anonimizados, tal como se entregaron a un cliente real.

Puntúe solo lo evidenciado. Una afirmación sin artefacto detrás puntúa cero. Dos evaluadores puntúan de forma independiente, las divergencias superiores a un punto se discuten y se resuelven por escrito, y la matriz ponderada se comparte con el comité antes de recibir respuestas, de modo que los pesos no puedan ajustarse después para favorecer a un proveedor preferido.

Ejecute una prueba de valor (PoV) con 2 o 3 finalistas sobre una porción realista de su entorno. Las métricas se definen y se acuerdan antes de empezar. Una PoV cuyos criterios de éxito se redactan después no demuestra nada; solo genera material para el caso de éxito del proveedor.

• Tiempo desde la conexión de la fuente de log hasta la primera detección validada.
• Tasa de falsos positivos y calidad de escalado sobre escenarios de prueba inyectados.
• Capacidad de respuesta y sustancia de la comunicación de los analistas durante el ejercicio.
• Legibilidad del informe resultante por un directivo no técnico, comprobada entregándoselo de verdad a uno.

Negocie el contrato contra las mismas métricas de resultado usadas en la PoV. Un SLA que mide el tiempo de acuse le dice cuán rápido cambia de estado un ticket. No le dice nada sobre si una intrusión real sería detectada y contenida. Cada nivel de servicio contractual debe mapear a una métrica que usted pueda verificar de forma independiente con sus propios datos, con penalizaciones asociadas y derecho de auditoría sobre las cifras reportadas por el proveedor.

SLA de respuesta no es SLA de detección. La confusión más cara en contratos de MSSP: un SLA de respuesta de 15 minutos suele significar que el ticket se acusó en 15 minutos. El rendimiento de detección, la calidad del triaje y la contención son obligaciones separadas. Si el contrato solo define respuesta, el proveedor puede cumplir todos sus SLAs durante una brecha que nunca detectó.

• Periodo de salida y handover suficiente para transicionar sin huecos de cobertura, con obligaciones de cooperación del proveedor declaradas.
• Devolución de logs y datos de casos en formatos abiertos y documentados, con retención garantizada durante la transición.
• Propiedad y traspaso de los runbooks y del contenido de detección desarrollado para usted durante el contrato.
• Reversibilidad ensayada sobre el papel antes de firmar: recorra el escenario de salida con el proveedor y deje las respuestas por escrito.

La firma es el inicio de la supervisión, no el final del proyecto. DORA (Reglamento (UE) 2022/2554) convierte la gestión del riesgo de terceros TIC en una obligación continua para las entidades financieras, y NIS2 (Directiva (UE) 2022/2555) extiende los deberes de seguridad de la cadena de suministro a entidades esenciales e importantes. Ambas esperan que usted demuestre que la capacidad externalizada se supervisa, no solo que se contrató.

El mecanismo práctico es una evaluación de madurez SOC independiente y periódica del alcance externalizado contra el SOC-CMM, el modelo creado por Rob van Os en 2016, hoy en la versión 2.4, con cinco dominios y 27 aspectos en una escala continua de 0 a 5. Evaluar el servicio operado por el proveedor con la misma vara que su línea base interna da al consejo una sola línea de tendencia: ¿la madurez que usted compró se está entregando de verdad y mejora año tras año? El octavo paso cierra el ciclo: decisión documentada, recomendación firmada y fecha de reevaluación agendada antes de la primera conversación de renovación.