Cómo evaluar a un proveedor de pentest: un cuestionario de 46 preguntas

Para evaluar a un proveedor de pentest, envíale un cuestionario por escrito y puntúa las respuestas con una misma escala: quién hará exactamente las pruebas, qué metodología sigue, qué pasará con tus datos, qué informe recibirás y quién responde si algo se rompe. Abajo tienes 46 preguntas así, en diez secciones; cada una lleva una línea de «Buena respuesta», para que incluso alguien sin formación técnica pueda valorar lo que contestan.

El cuestionario es neutral: sirve para evaluar a cualquier proveedor, también a nosotros. Complementa el artículo sobre cómo elegir una empresa de pentesting: allí se explica qué mirar y por qué; aquí tienes un documento de trabajo listo para copiar en un correo o en un formulario de licitación. Cómo preparar tu propia parte se explica en la lista de preparación para un pentest, y otras listas gratuitas están reunidas en la página de la checklist gratuita de ciberseguridad.

En resumen

• Envía las mismas preguntas y la misma descripción de tus sistemas a dos o tres proveedores y pide respuestas por escrito.
• Puntúa cada respuesta con 0, 1 o 2 puntos. Siete preguntas están marcadas como preguntas de corte: un cero en cualquiera de ellas significa que no sigues adelante con ese proveedor.
• Lo que más dice son tres cosas: los nombres de quienes harán las pruebas, un informe de muestra anonimizado y reglas escritas sobre tus datos, incluido el uso de herramientas de IA.
• Las metodologías deben nombrarse con precisión. A octubre de 2026 son PTES ^[1], OWASP WSTG 4.2 ^[2], OWASP MASVS 2.1.0 y MASTG 2.0.0 ^[3], NIST SP 800-115 (2008) ^[4] y OSSTMM 3 ^[5]; la gravedad suele valorarse con CVSS 4.0 o 3.1. ^[6]

Cómo usar el cuestionario

1. Copia las preguntas en un documento, añade una breve descripción de los sistemas que debe cubrir el pentest (qué se prueba, dónde, cuántos roles de usuario) y da a los proveedores 5-7 días hábiles para responder.
2. Pide respuestas por escrito y pruebas: un informe de muestra, una plantilla de contrato, una lista de certificaciones con números. Un «sí, claro» de palabra no cuenta como respuesta completa.
3. Puntúa cada respuesta:
   • 2 puntos: una respuesta escrita y concreta con pruebas, o disposición a incluirla en el contrato;
   • 1 punto: una respuesta general, «normalmente sí», sin detalles ni documento;
   • 0 puntos: sin respuesta, una respuesta evasiva o una respuesta de la lista de señales de alarma.
4. Revisa las preguntas de corte (marcadas con [corte]): un cero en una sola de ellas significa que no, sea cual sea el total.
5. Calcula el porcentaje sobre el máximo (92 puntos). Como orientación: desde el 75% puedes pasar al contrato, entre el 50% y el 75% hace falta una llamada de aclaración, por debajo del 50% conviene buscar otro proveedor.

Para una empresa pequeña no todas las preguntas pesan igual. Si alguna no aplica (por ejemplo, no tienes aplicaciones móviles), quítala del máximo para todos los proveedores.

El cuestionario: 46 preguntas

1. Empresa y entidad jurídica

1. ¿Qué entidad jurídica firma el contrato: nombre completo, país de registro, número de registro?
   Buena respuesta: la entidad aparece en el registro mercantil oficial y es la misma que firma el NDA y el contrato y emite la factura.
2. ¿Dónde están registrados los propietarios y dónde trabajan físicamente quienes hacen las pruebas?
   Buena respuesta: se nombran países y ciudades; no hay propietarios ni personal en jurisdicciones sancionadas u hostiles; el trabajo con tus datos se hace solo desde países acordados.
3. ¿Qué servicios ofrecen además del pentest? ¿Venden productos de seguridad o implantan sistemas que luego ellos mismos probarían?
   Buena respuesta: el conflicto de intereses se declara abiertamente y las recomendaciones del informe no están ligadas a productos que vende el proveedor.
4. ¿Ha habido en los últimos tres años incidentes con datos de clientes, litigios o quejas sobre su trabajo?
   Buena respuesta: un «no» honesto o un breve relato de lo que pasó y qué cambiaron después en sus procesos.
5. ¿Qué certificaciones o acreditaciones tiene la propia empresa (por ejemplo ISO/IEC 27001, CREST) y cuál es su alcance?
   Buena respuesta: una copia del certificado cuyo alcance cubre los servicios de pruebas. Para una empresa pequeña no tenerlo no es un suspenso si los procesos de las secciones 5 y 6 están descritos por escrito.

2. El equipo y quién hace realmente las pruebas

6. [corte] ¿Quién exactamente probará nuestro proyecto? Indiquen nombres, roles y experiencia de cada persona.
   Buena respuesta: nombres en la propuesta o el contrato; solo se puede sustituir a alguien con tu consentimiento por escrito.
7. ¿Qué certificaciones tienen esas personas concretas y cómo podemos verificarlas?
   Buena respuesta: el nombre del certificado (OSCP, GPEN, GWAPT, OSWE, CREST, etc.) con número o enlace al registro público del emisor, como el directorio de profesionales certificados de GIAC. ^[7] Los certificados de un directivo que no hará las pruebas no cuentan.
8. [corte] ¿Recurren a subcontratistas o freelancers?
   Buena respuesta: un «no» por escrito, o una lista de personas o empresas concretas que firman el mismo NDA y entran solo con tu consentimiento.
9. ¿Qué experiencia tiene el equipo con nuestro tipo de sistemas (aplicación web, API, apps móviles, nube, Active Directory, sistemas industriales)?
   Buena respuesta: ejemplos anonimizados de proyectos parecidos y una lista de pruebas específicas para tu stack. El NCSC aconseja señalar desde el principio los sistemas poco habituales para que el proveedor confirme que tiene esas habilidades. ^[8]
10. ¿Quién dirige el proyecto y quién revisa el informe antes de enviarlo?
    Buena respuesta: un responsable de proyecto con nombre y una segunda persona que revisa hallazgos y recomendaciones (peer review).
11. ¿Firman quienes hacen las pruebas compromisos personales de confidencialidad y los verifica la empresa al contratarlos?
    Buena respuesta: sí, NDA individuales; solo los miembros del proyecto acceden a tus datos.

3. Metodología y estándares

12. ¿En qué metodologías se basan y cómo las adaptan a nuestro proyecto?
    Buena respuesta: se nombran documentos concretos: PTES (siete fases desde los acuerdos previos hasta el informe) ^[1], OWASP WSTG para aplicaciones web (versión estable 4.2, la 5.0 en desarrollo) ^[2], OWASP MASVS y MASTG para apps móviles ^[3], NIST SP 800-115 ^[4], OSSTMM 3 ^[5]. Una «metodología propia y secreta» sin describir sus fases es una respuesta débil.
13. ¿Cuántas horas o días de trabajo manual de una persona y cuánto de escáneres automáticos? ¿Qué herramientas usan?
    Buena respuesta: las horas manuales figuran aparte; los escáneres solo ayudan y una persona verifica cada resultado.
14. ¿Cómo prueban la lógica de negocio y los permisos: puede un usuario ver los datos de otro?
    Buena respuesta: pruebas con al menos dos cuentas por rol y escenarios típicos descritos: saltarse roles, manipular peticiones, evitar el pago.
15. ¿Cómo descartan los falsos positivos?
    Buena respuesta: en el informe solo entra lo reproducido a mano; las suposiciones se marcan aparte.
16. ¿Qué tipo de prueba proponen (caja negra, gris o blanca) y por qué?
    Buena respuesta: la elección se explica por tu objetivo: por ejemplo, caja gris con cuentas de prueba da más cobertura en los mismos días.
17. ¿Cómo tienen en cuenta los requisitos que debemos cumplir (un regulador, PCI DSS, ISO/IEC 27001, exigencias de nuestros clientes)?
    Buena respuesta: el proveedor pregunta quién necesita el informe y propone un formato que acepte ese auditor o cliente concreto.

4. Alcance y reglas de actuación

18. ¿Cómo definen el alcance y qué quedará fuera?
    Buena respuesta: una lista escrita de sistemas, direcciones, roles y exclusiones. Si durante la prueba aparece un sistema importante fuera del alcance, decide el cliente: ampliar el alcance o registrarlo como limitación de la prueba. ^[8]
19. ¿En qué se basa su estimación de esfuerzo y plazos?
    Buena respuesta: un cálculo según el número de sistemas, roles, endpoints de API o direcciones, no un «paquete» fijo ofrecido sin una sola pregunta sobre tus sistemas.
20. ¿Qué acciones están prohibidas por defecto?
    Buena respuesta: las reglas de actuación lo dicen expresamente: ataques de denegación de servicio, borrar o modificar datos reales, correos a clientes reales, ingeniería social sin consentimiento aparte.
21. ¿Desde qué direcciones IP y en qué horario hacen las pruebas?
    Buena respuesta: direcciones fijas comunicadas de antemano, horario acordado, trabajo fuera de él solo con tu permiso.
22. [corte] ¿Qué hacen si a mitad de la prueba encuentran una vulnerabilidad crítica o rastros de una intrusión real?
    Buena respuesta: avisan de inmediato por el canal acordado sin esperar al informe; el plazo de aviso figura en las reglas de actuación.
23. ¿Cómo detenemos la prueba y quién está localizable por su parte?
    Buena respuesta: una persona con nombre y teléfono durante toda la ventana de pruebas y un procedimiento sencillo para parar.
24. ¿Cómo se aseguran de que tenemos derecho a autorizar pruebas sobre la nube, el hosting o servicios de terceros?
    Buena respuesta: el proveedor pregunta quién es el dueño de cada sistema y sigue las reglas del proveedor de nube; no prueba servicios ajenos sin permiso de su dueño.

5. Tus datos, NDA y herramientas de IA

25. [corte] ¿Firmamos un NDA antes de compartir cualquier dato, acceso o descripción de sistemas?
    Buena respuesta: sí, un NDA mutuo antes de cualquier detalle técnico.
26. ¿Dónde y cómo guardan las evidencias: capturas, extracciones de datos, credenciales?
    Buena respuesta: almacenamiento cifrado, país de alojamiento indicado, acceso solo para el equipo del proyecto, ningún portátil personal sin cifrar.
27. ¿Qué hacen con los datos personales a los que acceden durante la prueba?
    Buena respuesta: toman lo mínimo necesario como prueba, enmascaran los datos en el informe y no los extraen en masa.
28. [corte] ¿Cuánto tiempo conservan los datos del proyecto y cómo los eliminan?
    Buena respuesta: el plazo figura en el contrato y después se eliminan con confirmación por escrito.
29. [corte] ¿Usan herramientas de IA (chatbots, asistentes de código, escáneres con IA) con nuestros datos?
    Buena respuesta: una lista de herramientas; los datos del cliente nunca van a servicios públicos que entrenan con las consultas; uso con tus datos solo con tu consentimiento por escrito.
30. ¿Cómo entregan el informe, las contraseñas y los accesos?
    Buena respuesta: un canal o archivo cifrado con la contraseña por otro canal; nunca un adjunto en un correo normal.
31. ¿Qué pasa con las cuentas de prueba, los archivos subidos y otros rastros cuando termina la prueba?
    Buena respuesta: una lista de todo lo creado o modificado, limpieza tras la prueba y confirmación en el informe.

6. El informe

32. [corte] ¿Podemos ver una muestra anonimizada de un informe real?
    Buena respuesta: sí, un informe real sin nombres, no un folleto comercial.
33. ¿Qué escala de gravedad usan y de qué versión?
    Buena respuesta: se indica la versión de CVSS (la actual es 4.0; la 3.1 también es habitual) con el vector de cada hallazgo, más una valoración del riesgo para tu negocio en concreto. ^[6] Cualquier desviación de la puntuación estándar la justifica quien hace la prueba. ^[8]
34. ¿Hay un resumen ejecutivo breve sobre el impacto en el negocio?
    Buena respuesta: una o dos páginas en lenguaje claro: qué se encontró, qué riesgo supone, qué corregir primero.
35. ¿Cada hallazgo incluye pasos para reproducirlo y evidencias?
    Buena respuesta: sí, tu desarrollador puede reproducir cada hallazgo por su cuenta.
36. ¿Qué tan concretas son las recomendaciones?
    Buena respuesta: qué cambiar exactamente en el código o la configuración, no «mejorar el nivel de seguridad», con enlaces a documentación.
37. ¿En qué idioma estará el informe?
    Buena respuesta: en el que necesites (español, inglés o ambos), con el mismo contenido; el segundo idioma está incluido en el precio o aparece como línea aparte.
38. ¿Cuándo recibiremos el informe y podemos comentarlo con quien hizo la prueba?
    Buena respuesta: el plazo tras terminar la prueba figura en el contrato y una reunión para repasar el informe está incluida en el precio.

7. Retest

39. ¿El retest está incluido en el precio, cuántas veces y en qué plazo?
    Buena respuesta: sí, el número de retests y la ventana para hacerlos figuran en el contrato.
40. ¿Qué recibimos después del retest?
    Buena respuesta: un informe actualizado o un anexo con el estado de cada hallazgo: corregido, parcialmente, abierto.
41. ¿Pueden emitir una carta que confirme la prueba para nuestros clientes o auditor?
    Buena respuesta: sí, con hechos (qué se probó, cuándo y con qué alcance) y sin promesas de que «el sistema es totalmente seguro».

8. Seguro y responsabilidad

42. ¿Tiene la empresa un seguro de responsabilidad profesional o un ciberseguro? ¿Qué cobertura?
    Buena respuesta: se indican la aseguradora y el límite, o se explica cómo cubre el contrato la responsabilidad.
43. ¿Quién responde si la prueba provoca una caída o una pérdida de datos, y dónde está escrito?
    Buena respuesta: una cláusula propia en el contrato con límite de responsabilidad y un procedimiento, no «no va a pasar nada».
44. ¿De quién son el informe y los resultados, y pueden mencionarnos como cliente?
    Buena respuesta: el informe es tuyo; solo te mencionan con consentimiento por escrito.

9. Precio y contrato

45. ¿Qué incluye el precio, qué se factura aparte y qué pasa si cambia el alcance?
    Buena respuesta: líneas separadas para días de trabajo, informe, idiomas, retest y desplazamientos; los cambios de alcance solo por acuerdo escrito antes de empezar el trabajo extra.

10. Referencias y reputación

46. ¿Pueden darnos el contacto de un cliente para una llamada breve o mostrar su experiencia públicamente?
    Buena respuesta: un contacto de cliente con su consentimiento o una descripción anonimizada del proyecto; suman las investigaciones públicas, charlas o vulnerabilidades publicadas que se puedan comprobar. Negarse a nombrar clientes por NDA es normal.

Señales de alarma

Cualquier cosa de esta lista vale 0 puntos en la pregunta correspondiente, aunque el resto de la respuesta sea buena:

• «Lo probamos todo», sin lista de sistemas ni exclusiones.
• Un precio de inmediato, sin una sola pregunta sobre tus sistemas.
• Los nombres de quienes harán las pruebas «tras el pago», o el equipo cambia sin aviso.
• Un informe al día siguiente de empezar, o un informe de muestra que parece una exportación de escáner.
• «Garantizamos que no quedará ninguna vulnerabilidad».
• Ninguna respuesta sobre qué pasa con tus datos tras el proyecto, o tus datos van a servicios públicos de IA sin tu consentimiento.
• Presión: «descuento solo hoy», «empezamos sin contrato y los papeles después».
• Pruebas activas antes de firmar el NDA y la autorización por escrito.

Versión corta en una página

Si no hay tiempo para el cuestionario completo, empieza por estas 12 preguntas. Lo que sigue a «Bien» indica qué es una buena respuesta. Marca un punto solo si el proveedor respondió así por escrito. Los puntos marcados con [corte] son obligatorios.

• [corte] Equipo. ¿Quién hará las pruebas? Bien: nombres y certificados con número.
• [corte] Subcontratas. ¿Participa alguien más? Bien: «no», o solo con nuestro permiso.
• Método. ¿Qué metodología? Bien: PTES, OWASP o NIST, días manuales aparte.
• Alcance. ¿Qué van a probar? Bien: lista escrita de sistemas, roles y exclusiones.
• Reglas. ¿Cómo evitarán romper producción? Bien: prohibiciones, IP, horario, quién para.
• [corte] Crítico. ¿Cuándo nos avisan? Bien: de inmediato, sin esperar al informe.
• [corte] Datos. ¿Y las evidencias? Bien: NDA antes, cifrado, borrado con confirmación.
• [corte] IA. ¿Van nuestros datos a servicios de IA? Bien: solo con permiso escrito.
• [corte] Informe. ¿Hay muestra? Bien: anonimizada, versión de CVSS, resumen ejecutivo.
• Retest. ¿Está en el precio? Bien: número de retests y plazos en el contrato.
• Responsabilidad. ¿Quién responde de una caída? Bien: cláusula, límite, seguro.
• Precio. ¿Qué incluye? Bien: líneas separadas, cambios de alcance solo por escrito.

Descargar la lista de preparación (PDF)PDF · A4

FAQ

¿A cuántos proveedores conviene enviarlo?

Con dos o tres basta. Lo importante es enviar a todos las mismas preguntas y la misma descripción de sistemas; si no, las respuestas no se pueden comparar con justicia.

¿Se puede acortar el cuestionario?

Sí. Para un proyecto pequeño quédate con la versión corta de una página y todas las preguntas de corte. Las preguntas que no te apliquen quítalas del máximo para todos los proveedores por igual.

¿Qué hago si un proveedor no quiere responder por escrito?

Eso ya es una respuesta. Es razonable que algunos detalles lleguen después del NDA, pero un buen proveedor da por escrito los nombres de quienes harán las pruebas, un informe de muestra y las reglas sobre tus datos.

¿Es obligatorio que el proveedor tenga ISO/IEC 27001 o CREST?

No. Es un punto a favor, sobre todo para grandes clientes y sectores regulados, pero para una empresa pequeña pesan más los nombres de quienes harán las pruebas, un informe de muestra y reglas escritas sobre los datos.

¿Puedo usar este cuestionario en una licitación?

Sí. Las preguntas son neutrales y encajan en un formulario de licitación. Añade la descripción de tus sistemas y los requisitos de formato del informe para que todos los participantes presupuesten el mismo alcance.

Referencias

1. The Penetration Testing Execution Standard (PTES) pentest-standard.org
2. OWASP Web Security Testing Guide (WSTG) owasp.org
3. OWASP Mobile Application Security: MASVS y MASTG mas.owasp.org
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. ISECOM: OSSTMM 3, Open Source Security Testing Methodology Manual isecom.org
6. FIRST: Common Vulnerability Scoring System v4.0 first.org
7. GIAC: Certified Professionals directory giac.org
8. NCSC: Penetration testing ncsc.gov.uk