Cómo evaluar a un proveedor de ciberseguridad antes de firmar
Para evaluar a un proveedor de ciberseguridad, compruebe 5 cosas antes de firmar: qué hará exactamente, qué accesos necesita, cómo demuestra su propia seguridad, cómo informa de los hallazgos y los incidentes, y qué pasa con sus datos cuando termina el contrato. Pida cada respuesta por escrito y compárela con el contrato.
Esto importa porque un proveedor de seguridad es un proveedor con un alcance poco habitual. Algunos solo vigilan su empresa desde fuera, otros instalan agentes en cada dispositivo, otros tienen credenciales de administrador. La guía de CISA para clientes de proveedores de servicios gestionados lo dice claramente: externalizar la gestión de TI "no exime a una organización de sus responsabilidades de gestión del riesgo".
Las preguntas siguientes sirven para servicios de monitorización, pentesters, detección y respuesta gestionadas (MDR) y consultores.
1. Defina el alcance con un lenguaje claro
Pida al proveedor que describa, en un párrafo, qué hará y qué no hará. Una buena respuesta nombra los activos (dominios, rangos de IP, aplicaciones, dispositivos), las actividades (monitorización, pruebas, configuración, respuesta) y la frecuencia.
Desconfíe de:
- Descripciones vagas como "protección total" sin una lista de activos.
- Actividades que modifican sus sistemas sin un paso de aprobación claro.
- Entregables que son solo una puntuación o un panel, sin explicación de cada hallazgo.
2. Entienda qué accesos necesita y por qué
El acceso es la mayor diferencia entre proveedores. Pregunte:
- ¿Necesitan credenciales, acceso por VPN, un agente o una clave de API? ¿Para qué exactamente?
- ¿El acceso es de solo lectura o puede cambiar la configuración?
- ¿Cada cuenta es nominativa, está protegida con autenticación multifactor y queda registrada?
- ¿Con qué rapidez podemos revocarlo?
CISA recomienda limitar las cuentas del proveedor a los sistemas que gestiona y mantenerlas fuera de los grupos de administradores. Si un servicio puede funcionar con menos acceso, prefiera ese diseño. Algunos servicios, como la monitorización de la superficie de ataque externa, no necesitan ninguno (consulte qué es la monitorización de la superficie de ataque externa).
3. Exija autorización por escrito para cualquier prueba
Cualquier actividad que sondee o pruebe sus sistemas necesita su autorización por escrito, con los objetivos exactos y la franja horaria. En EE. UU., acceder a un ordenador sin autorización está tipificado en la Computer Fraud and Abuse Act, 18 U.S.C. 1030, y otros países tienen leyes similares.
Un proveedor profesional le pedirá este documento antes de empezar. Tenga cuidado con quien se ofrezca a probar sistemas que no son suyos, como la web de un socio, o empiece a escanear antes de que se firme la documentación. Eso también le indica cómo tratará los sistemas de otros mientras trabaja para usted.
4. Pida pruebas y después compruébelas
Las afirmaciones de una presentación comercial no son pruebas. Solicite:
- Informes de auditoría independientes o certificaciones cuando proceda, como un informe SOC 2 o la certificación ISO/IEC 27001. Revise el alcance: qué servicios y ubicaciones cubre.
- Un informe de ejemplo con hallazgos, para valorar si sus desarrolladores podrían actuar a partir de él.
- Quién revisa los hallazgos: una persona o solo un resultado automatizado.
- Una lista de sus subcontratistas y del lugar donde se almacenan sus datos.
Después haga su propia comprobación rápida de la higiene externa del proveedor. Una empresa de seguridad debería cumplir lo básico:
dig +short TXT _dmarc.provider-example.com
curl -sI https://provider-example.com | grep -i -E "strict-transport|content-security"
La falta de un registro DMARC o de cabeceras de seguridad no demuestra un mal trabajo, pero es una pregunta legítima. Nuestros artículos sobre SPF, DKIM y DMARC y sobre las cabeceras de seguridad HTTP explican qué buscar.
5. Acuerde los informes, los incidentes y la salida
Hallazgos e incidentes
Pregunte cómo le llega un hallazgo: ¿por correo, ticket, teléfono, un portal? ¿Quién lo recibe y con qué rapidez? Un buen hallazgo indica qué se ha visto, por qué importa y los pasos exactos para corregirlo.
Para los incidentes que le afecten, incluya en el contrato una obligación de notificación. Si está sujeto a NIS2 o vende a empresas que lo están, el Reglamento de Ejecución (UE) 2024/2690 (anexo, punto 5.1.4) enumera cláusulas contractuales como notificar los incidentes sin demora indebida, el derecho a auditar o a recibir informes de auditoría, la gestión de vulnerabilidades, las reglas de subcontratación y las obligaciones al terminar el contrato. Es una plantilla útil incluso fuera de su ámbito; consulte NIS2 para proveedores.
Planifique la salida antes de empezar
Pregunte qué ocurre cuando termina el contrato:
- Qué datos tienen sobre usted y cómo se devuelven y se eliminan.
- Cómo se retiran sus accesos, agentes y cuentas, y cómo puede confirmarlo usted.
- Si los informes y el historial siguen a su disposición.
- Los plazos de preaviso y si puede cambiar de proveedor sin perder sus registros.
Una lista de comprobación breve
- Alcance por escrito: activos, actividades, frecuencia.
- Acceso mínimo, cuentas nominativas, autenticación multifactor, revocación sencilla.
- Autorización por escrito antes de cualquier prueba.
- Informes de auditoría o certificaciones, con el alcance revisado.
- Informe de ejemplo con pasos de corrección aplicables, revisado por una persona.
- Cláusulas de notificación de incidentes en el contrato.
- Subcontratistas y ubicación de los datos indicados.
- Plan de salida: devolución de datos, eliminación y retirada de accesos.
Cómo trabaja Datahorses
Datahorses vigila su empresa desde fuera cada día, ve lo que puede ver un atacante y le envía cada hallazgo con los pasos exactos para corregirlo, revisado por una persona. No entramos en sus sistemas y no necesitamos accesos, así que no hay ninguna cuenta que revocar. Puede leer cómo vigilamos, las preguntas frecuentes y quiénes somos, o ver el panel de ejemplo completo antes de decidir.
Más artículos
PHP2Shell: qué versiones de PHP están corregidas y cómo comprobar la suya
El proyecto PHP corrigió 2 fallos críticos el 21 de octubre de 2026. Le explicamos qué versiones incluyen el parche, qué indica su servidor y qué preguntar a su proveedor de hosting.
SPF, DKIM y DMARC explicados para responsables de empresa
3 registros DNS deciden si alguien puede enviar correos que parezcan venir de su dominio. Esto es lo que hace cada uno y cómo revisar los suyos en minutos.
Fraude del CEO y suplantación de directivos: cómo la ingeniería social apunta a los pagos
Un mensaje que parece venir de su CEO pide un pago urgente y confidencial. Así funciona la suplantación de directivos y estas son las reglas sencillas que la desactivan.