25 preguntas para evaluar un proveedor SOC/MDR antes de contratar
Use estas preguntas para revisar alcance, telemetría, detección, respuesta, threat hunting, automatización, métricas y gobierno antes de comparar una propuesta solo por precio o promesas.
No busque una respuesta perfecta; busque definiciones que puedan verificarse.
Puede usar una escala simple de 0 a 2 por pregunta. El puntaje no certifica un proveedor: sirve para identificar vacíos que deben aclararse antes de contratar.
No definido o respuesta genérica.
Parcialmente definido, con dependencias por aclarar.
Definido, demostrable y reflejado en alcance o contrato.
Alcance y modelo operativo
01. ¿Qué modelo de servicio están ofreciendo exactamente: optimización de SOC, cogestión o MDR?
Por qué importa: Porque las tres modalidades pueden usar tecnologías similares, pero distribuyen de forma distinta la responsabilidad operativa, la investigación y la respuesta.
Busque evidencia de: Una definición explícita de qué actividades ejecuta el proveedor, cuáles conserva el cliente y qué resultados se esperan de cada parte.
02. ¿Cuál es la cobertura horaria real y qué ocurre fuera de esa ventana?
Por qué importa: Porque decir “SOC” o “MDR” no implica automáticamente atención 24/7 ni los mismos tiempos de reacción.
Busque evidencia de: Horario contractual, mecanismo de guardia si existe, canales de escalamiento, zonas horarias, festivos y tratamiento de eventos fuera de cobertura.
03. ¿Qué responsabilidades quedan documentadas entre proveedor, cliente y terceros?
Por qué importa: Porque muchos incidentes se retrasan cuando nadie sabe quién puede investigar, bloquear, aislar o aprobar una acción.
Busque evidencia de: RACI o matriz equivalente, responsables de aprobación, contactos de emergencia y límites claros de autoridad.
04. ¿Qué activos, usuarios, sedes, nubes, aplicaciones y unidades de negocio estarán realmente dentro del alcance?
Por qué importa: Porque un contrato puede parecer amplio mientras deja fuera fuentes o activos que son críticos para detectar una intrusión.
Busque evidencia de: Inventario o matriz de cobertura con inclusiones, exclusiones, criticidad y dependencias conocidas.
05. ¿Cómo se incorporan nuevos activos, fuentes de telemetría o cambios de arquitectura durante el servicio?
Por qué importa: Porque la cobertura de detección se degrada si el servicio no cambia al ritmo de la organización.
Busque evidencia de: Proceso de onboarding y cambio, responsables, tiempos, criterios de aceptación y revisión periódica del alcance.
Telemetría e ingeniería de detección
06. ¿Qué fuentes de telemetría necesitan y cómo identifican brechas de visibilidad?
Por qué importa: Porque no se puede detectar de forma consistente aquello sobre lo que no existe señal suficiente o confiable.
Busque evidencia de: Matriz de fuentes por caso de uso, estado de integración, calidad de datos, retención y brechas conocidas.
07. ¿Cómo incorporan contexto de activos, identidades, exposición y criticidad en las alertas?
Por qué importa: Porque una misma señal puede significar cosas muy distintas en un servidor crítico, una cuenta privilegiada o un activo de baja relevancia.
Busque evidencia de: Enriquecimiento con inventario, identidad, vulnerabilidades, privilegios, exposición externa y contexto de negocio cuando esté disponible.
08. ¿Cómo crean, priorizan y mantienen los casos de uso de detección?
Por qué importa: Porque un catálogo estático envejece frente a cambios de arquitectura, amenazas y comportamiento del entorno.
Busque evidencia de: Backlog de detección, criterios de prioridad, propietario, pruebas, versionado, tuning y ciclo de revisión.
09. Si utilizan MITRE ATT&CK, ¿cómo conectan el mapeo con detecciones y analíticas concretas?
Por qué importa: Porque una matriz ATT&CK coloreada no demuestra por sí sola que exista cobertura efectiva ni que las detecciones funcionen.
Busque evidencia de: Mapeo a técnicas relevantes, Detection Strategies o analíticas aplicables, telemetría requerida, pruebas y evidencia de funcionamiento.
10. ¿Cómo miden y reducen falsos positivos sin aumentar silenciosamente los falsos negativos?
Por qué importa: Porque bajar el volumen de alertas no equivale necesariamente a mejorar la detección.
Busque evidencia de: Proceso de tuning con revisión de impacto, razones de supresión, excepciones documentadas, pruebas y métricas de calidad de señal.
Triage, investigación y respuesta
11. ¿Cómo clasifican severidad y prioridad durante el triage?
Por qué importa: Porque la criticidad debe considerar más que el nombre de una regla o la severidad que asigna una herramienta.
Busque evidencia de: Criterios que combinen comportamiento, confianza de la señal, activo afectado, identidad, exposición, impacto y contexto del incidente.
12. ¿Qué información recibirá nuestro equipo cuando un caso sea escalado?
Por qué importa: Porque una notificación sin contexto traslada el trabajo de investigación de vuelta al cliente.
Busque evidencia de: Resumen ejecutivo, línea de tiempo, entidades afectadas, evidencia relevante, hipótesis, severidad razonada y acciones recomendadas.
13. ¿Qué acciones de respuesta puede ejecutar el proveedor y cuáles requieren autorización?
Por qué importa: Porque aislar un endpoint, bloquear una cuenta o modificar una regla puede reducir impacto, pero también afectar la operación.
Busque evidencia de: Matriz de acciones preautorizadas, acciones sujetas a aprobación, mecanismo de emergencia, registro de cambios y posibilidad de reversión.
14. ¿Cómo se integra el SOC/MDR con nuestro proceso de respuesta a incidentes?
Por qué importa: Porque detectar y escalar no es suficiente si el caso se pierde al pasar de monitoreo a contención, recuperación o forense.
Busque evidencia de: Runbooks compartidos, criterios de activación, contactos, escalamiento, handoff, reuniones de crisis y coordinación con equipos internos o terceros.
15. ¿Cómo registran investigaciones, decisiones y evidencia para que el caso sea trazable?
Por qué importa: Porque después de un incidente se necesita reconstruir qué ocurrió, qué se decidió y por qué.
Busque evidencia de: Case management, línea de tiempo, evidencias, responsables, decisiones, acciones ejecutadas y retención definida de los registros del caso.
Threat hunting, inteligencia y automatización
16. ¿El threat hunting es una capacidad real del servicio o una actividad ocasional sin frecuencia definida?
Por qué importa: Porque “incluye hunting” puede significar desde búsquedas periódicas basadas en hipótesis hasta una actividad ad hoc difícil de verificar.
Busque evidencia de: Frecuencia, metodología, hipótesis, fuentes utilizadas, resultados, hallazgos y retroalimentación hacia detecciones.
17. ¿Cómo convierten inteligencia de amenazas en decisiones operativas?
Por qué importa: Porque acumular indicadores o feeds no aporta valor si no cambia qué se busca, prioriza o investiga.
Busque evidencia de: Ejemplos de inteligencia aplicada a hipótesis, enriquecimiento, nuevas detecciones, priorización de campañas o cambios de monitoreo.
18. ¿Qué tareas automatizan con SOAR o playbooks y qué controles existen sobre esas automatizaciones?
Por qué importa: Porque automatizar enriquecimiento puede reducir tiempos, pero automatizar contención sin gobierno puede introducir riesgo operativo.
Busque evidencia de: Inventario de playbooks, acciones permitidas, aprobaciones, manejo de errores, registro de ejecución y revisiones periódicas.
19. ¿Cómo retroalimentan las investigaciones para mejorar detecciones y procesos?
Por qué importa: Porque un SOC madura cuando aprende de señales reales, no solo cuando procesa más eventos.
Busque evidencia de: Proceso documentado para convertir incidentes, falsos positivos, hunts y cambios de entorno en mejoras de reglas, contexto, playbooks o cobertura.
20. ¿Cómo prueban que una detección nueva o modificada funciona antes de considerarla operativa?
Por qué importa: Porque una regla desplegada no equivale a una detección validada.
Busque evidencia de: Casos de prueba, simulaciones o datos controlados, criterios de aceptación, control de cambios y evidencia de resultados.
Gobierno, métricas y condiciones contractuales
21. ¿Qué métricas usarán para demostrar calidad y mejora, además del número de alertas?
Por qué importa: Porque contar eventos o tickets puede premiar el volumen y ocultar problemas de cobertura o precisión.
Busque evidencia de: Métricas de calidad de señal, cobertura, tiempos operativos, backlog, tuning, uso de casos, investigación, hunting y acciones de mejora con definiciones claras.
22. ¿Qué cadencia de gobierno y revisión tendrá el servicio?
Por qué importa: Porque los problemas de alcance, telemetría y responsabilidades necesitan un foro para resolverse antes de convertirse en incidentes.
Busque evidencia de: Reuniones operativas y de gobierno, agenda, responsables, decisiones, riesgos abiertos, acciones y seguimiento.
23. ¿Cómo están definidos los SLA y desde qué momento empieza a medirse cada uno?
Por qué importa: Porque “respuesta en 15 minutos” puede referirse a recepción, triage, notificación o contención, que son cosas distintas.
Busque evidencia de: Definiciones contractuales de inicio y fin, severidad, horario aplicable, exclusiones, dependencias del cliente y tratamiento de incumplimientos.
24. ¿Cómo protegen nuestros datos, registros y credenciales, y qué terceros participan en el servicio?
Por qué importa: Porque un MDR accede a telemetría sensible y, en algunos casos, a capacidades con privilegios elevados.
Busque evidencia de: Controles de acceso, MFA, segregación, logging administrativo, cifrado, retención, subprocesadores, ubicación de datos y procedimiento de baja de accesos.
25. ¿Qué podremos conservar y exportar si terminamos el servicio o cambiamos de proveedor?
Por qué importa: Porque la salida debe preservar conocimiento operativo y evitar dependencia innecesaria del proveedor.
Busque evidencia de: Plan de transición, exportación de casos, documentación, reglas o contenidos acordados, revocación de accesos, borrado o retención de datos y responsabilidades de cierre.
Respuestas que conviene aclarar antes de firmar.
No significan automáticamente que el proveedor sea inadecuado, pero sí que existe una expectativa importante que aún no está suficientemente definida.
Marcos utilizados como referencia para estructurar la guía.
La guía es material práctico de Cyarax. No sustituye una evaluación técnica, contractual o legal y no representa una certificación frente a estos marcos.
NIST Cybersecurity Framework (CSF) 2.0 — resultados de gobierno, detección, respuesta y mejora dentro de la gestión de riesgo.
NIST SP 800-61 Rev. 3 — recomendaciones de respuesta a incidentes integradas con CSF 2.0.
MITRE ATT&CK Detection Strategies — referencia para conectar comportamientos adversarios con estrategias y analíticas de detección.
CISA — Event Logging and Threat Detection — principios de logging y visibilidad para detección de amenazas.
¿Quiere aplicar estas preguntas a su SOC actual o a una propuesta que está evaluando?
Podemos revisar cobertura, telemetría, casos de uso, responsabilidades y condiciones operativas para identificar qué debe aclararse antes de definir el modelo.