Cómo elegir una empresa de pentesting: guía CISO

Cómo elegir una empresa de pentesting es una pregunta que un CISO responde una vez al año, pero la respuesta condiciona toda la postura de seguridad técnica de la organización: qué vulnerabilidades se descubren, cuán reproducible es la prueba, cómo se prioriza la remediación y si el informe sirve después delante de un auditor de NIS2, DORA, PCI DSS o ISO 27001. La mayoría de RFPs de pentesting comparan precio y entregables superficiales, pero los hallazgos que cambian el trabajo de un equipo de seguridad dependen de tres factores que rara vez aparecen en el cuadro comparativo: el perfil técnico real del equipo asignado, la metodología documentada y la calidad del informe que realmente entregan.

Esta guía se centra en la contratación de la auditoría ofensiva: qué criterios técnicos exigir al proveedor, las señales de alerta que conviene detectar antes de firmar, cómo estructurar el RFP para que las propuestas sean comparables, las preguntas concretas para la primera reunión técnica y qué evidencia pide cada marco de cumplimiento. Si la decisión es más amplia (SOC gestionado, consultoría GRC, respuesta a incidentes) y necesitas el mapa de proveedores del mercado español, la guía dedicada es empresas de ciberseguridad en España: cómo elegir.

Qué hace que una empresa de pentesting sea buena

Cinco rasgos que comparten los proveedores que valen la pena:

1. Equipo identificable y técnicamente activo. Los nombres del equipo aparecen en charlas, advisories, CVEs publicados, contribuciones a herramientas open source o write-ups públicos. Si la web sólo muestra logos de clientes y nadie del equipo tiene huella técnica reciente, la auditoría suele ser superficial.
2. Metodología trazable a un estándar reconocido. OWASP WSTG y OWASP MASTG para web y móvil, OWASP API Security Top 10 para API, PTES y NIST SP 800-115 para infraestructura, MITRE ATT&CK para red team. El proveedor debe poder explicar con qué metodología trabaja, qué casos de prueba de la guía ha cubierto y cuáles ha descartado por alcance, y mapear cada hallazgo al control o a la técnica correspondiente.
3. Informe de muestra anonimizado disponible. Lo que se entrega de verdad, no la plantilla de marketing. Mira: claridad del resumen ejecutivo separado del técnico, severidad CVSS justificada, prueba de concepto reproducible (request HTTP, captura, script), recomendaciones priorizadas por esfuerzo y referencias al estándar.
4. Retest incluido en el alcance original. Tras los fixes, el equipo valida cada hallazgo y emite un certificado de remediation. Si el retest se cobra como extra, el proveedor monetiza tu hallazgo en lugar de cerrarlo.
5. Capacidad de adaptarse al sector. Auditar fintech, salud, sector público o industria pide perfiles distintos. Un equipo serio te dirá si no es su nicho en lugar de aceptar y aprender con tu dinero.

Señales de alerta antes de firmar

Cinco patrones que sistemáticamente correlacionan con auditorías flojas:

• Propuesta cerrada antes de scoping técnico. Si el comercial cotiza el alcance sin que un técnico haya hecho preguntas (cuántos endpoints, qué tipos de usuario, qué módulos críticos, cuántos roles, hay autenticación SSO o por API key), el equipo va a improvisar al llegar y el alcance no encaja con la realidad.
• Sólo escáner automatizado disfrazado. La propuesta promete "auditoría exhaustiva" pero el entregable real es un PDF generado por Nessus, Acunetix, Burp Pro o MobSF con maquillaje encima. Identificable porque el listado de bugs se parece sospechosamente al output del escáner y la prueba de concepto es genérica.
• Equipo subcontratado en cascada. La empresa principal vende, una segunda empresa coordina, freelancers de varios países ejecutan. Cada eslabón rebaja el margen y la calidad. La forma de detectarlo: pide los nombres de las personas que harán el trabajo y verifica su huella pública.
• Sin investigación propia ni contribución pública. Una empresa de pentesting que en cinco años no ha publicado un advisory, una charla técnica o una herramienta open source rara vez tiene el músculo técnico de la propuesta.
• Informe incomprensible o templado al estilo "informe de auditoría financiera". El informe técnico debe ser una herramienta operativa para tu equipo de desarrollo. Si es un documento corporativo de 400 páginas con riesgos abstractos y sin payloads concretos, no sirve para arreglar nada.

Boutique, Big Four, MSSP o fabricante: qué cambia para el pentesting

El mercado español de proveedores se organiza en cuatro perfiles (boutique especializada, división cyber de una Big Four, MSSP con servicio profesional y fabricante que audita su propia plataforma). El mapa completo, con ejemplos de cada categoría y cuándo encaja cada una, está en tipos de empresa de ciberseguridad en España y no se repite aquí.

Para el pentesting en concreto, el tipo de empresa importa menos que tres preguntas que conviene hacer a cualquiera de ellas:

• ¿La auditoría ofensiva es el producto principal o una línea accesoria? Cuando es accesoria (habitual en MSSP y consultoras generalistas), el perfil del equipo asignado y la prioridad de tu cuenta determinan el resultado más que la marca.
• ¿Quién ejecuta realmente la prueba? Una Big Four que subcontrata a una boutique y firma encima puede entregar un buen informe; el problema es no saberlo antes de firmar. Pide el equipo nominado en la propuesta.
• ¿Cubre toda tu superficie? Los servicios profesionales de un fabricante conocen las internals de su plataforma, pero rara vez cubren un alcance heterogéneo (multi-cloud, varios SaaS, infraestructura on-prem) sin dejar huecos.

Cómo comparar propuestas en un RFP de pentesting

La forma de evitar comparar peras y manzanas:

1. Define el alcance tú primero. Qué activos, qué entornos, qué credenciales, qué horario. Sin alcance fijo, cada propuesta inventa el suyo y no se pueden comparar números.
2. Pide propuestas con la misma metodología explícita. Web sobre OWASP WSTG, móvil sobre OWASP MASVS, API sobre OWASP API Security Top 10. Si un proveedor cambia la metodología pactada, también cambia la profundidad.
3. Compara perfiles concretos del equipo asignado, no la plantilla de la empresa. CV técnico, advisories firmados, charlas, certificaciones (OSCP, OSWE, OSEP, CRTO) si aplican.
4. Revisa el informe de muestra anonimizado. Si no lo entregan, descarta. Es el único entregable que importa.
5. Pregunta por el plazo de retest y si está incluido o cuesta extra.
6. Aclara la propiedad del informe y de los hallazgos. Sigue siendo tuyo, sin cláusulas que limiten compartirlo con auditores externos.
7. Comprueba seguro de responsabilidad civil profesional y NDA estándar.

Preguntas que separar al equipo serio del que sólo cumple

Ocho preguntas concretas para una primera reunión técnica con el proveedor:

1. ¿Quién va a ejecutar la prueba? Nombre, perfil y huella pública.
2. ¿Qué metodología aplicáis y dónde está documentada? Si la respuesta es "metodología propia" sin más, mala señal.
3. ¿Cómo justificáis severidad CVSS de cada hallazgo? Cualquier respuesta vaga indica que se rellena el CVSS por norma.
4. ¿Qué entregáis exactamente como prueba de concepto? Petición HTTP cruda, script, captura, vídeo, contenido del payload.
5. ¿Cómo manejáis hallazgos críticos durante la prueba? ¿Se notifica inmediatamente o se espera al informe final?
6. ¿Hay retest incluido? ¿En qué plazo? ¿Qué emite (informe nuevo, certificado, anexo)?
7. ¿Cuántas auditorías en este sector habéis hecho en los últimos 12 meses?
8. ¿Podéis enseñar advisories propios, charlas o investigación firmada por miembros del equipo asignado?

Empresas de pentesting y compliance: NIS2, DORA, ISO 27001, PCI DSS

Para cumplir, no vale cualquier auditoría. Lo que pide cada marco:

• NIS2 (artículo 21). Eficacia de las medidas técnicas demostrada para entidades esenciales e importantes. La auditoría debe documentar metodología, alcance representativo y evidencia reproducible, porque la autoridad competente puede pedir el informe. En España, INCIBE-CERT actúa como CSIRT de referencia para el sector privado. Detalle en cómo cumplir NIS2 en España.
• DORA (artículos 24 a 27). Pruebas de resiliencia operativa digital con frecuencia mínima anual y, para las entidades que designe la autoridad competente, pruebas de penetración guiadas por amenazas (TLPT) al menos cada tres años siguiendo el marco TIBER-EU. El artículo 27 fija requisitos para los probadores: capacidad técnica y organizativa acreditada, independencia, seguro de responsabilidad civil profesional y equipo de red team separado del de inteligencia de amenazas. Detalle en DORA: guía de cumplimiento.
• ISO 27001:2022 (control 8.29). Pruebas de seguridad en el ciclo de vida del software. La auditoría documentada (con metodología, hallazgos, correcciones y retest) es evidencia directa para el control.
• PCI DSS v4.0 (requisito 11.4). Pentesting interno y externo al menos anual y tras cualquier cambio significativo. El proveedor debe seguir una metodología aceptada por la industria (PTES, OWASP, NIST SP 800-115) y el equipo debe ser organizativamente independiente del responsable de los activos auditados. El texto del requisito y la guía de pentesting del PCI SSC están en su biblioteca de documentos.

Pedir al proveedor que indique en propuesta a qué controles concretos se mapea el entregable simplifica el trabajo del auditor y evita rehacer auditorías porque no encajan con el marco.

Factores que determinan el precio (sin entrar en cifras concretas)

El presupuesto de una auditoría depende de variables que conviene tener identificadas antes de pedir oferta:

• Tipo de activo: web, móvil, API, infraestructura interna o externa, cloud, IoT/OT, red team. El esfuerzo unitario varía mucho.
• Tamaño del alcance: número de endpoints, módulos, roles, dispositivos, instancias cloud.
• Profundidad metodológica: black-box, grey-box (con credenciales) o white-box (con código fuente y arquitectura). La grey-box suele dar mejor relación calidad/coste.
• Compliance objetivo: TLPT bajo DORA o pentest PCI piden perfiles y evidencias específicas que elevan el esfuerzo.
• Plazos: una auditoría con plazo agresivo (urgente para release) cuesta más que una planificada con dos meses de antelación.
• Alcance de retest: incluir 1, 2 o N retests cambia la cifra final.

Lo más útil al comparar ofertas no es la cifra absoluta sino el coste por jornada-persona del equipo y la duración propuesta para el mismo alcance. Dos propuestas con la misma cifra final pueden esconder un factor de tres en horas reales dedicadas. Los rangos orientativos por tipo de activo están en cuánto cuesta un pentesting en España.

Lo que vemos en los encargos

Cuatro señales en una propuesta que nos indican que el trabajo será un escaneo automatizado con un informe encima: un precio cerrado sin haber preguntado por roles, endpoints ni entorno; un plazo de uno o dos días; ningún nombre ni certificación del equipo que ejecuta; y un entregable que es la exportación de una herramienta.

Preguntas frecuentes

¿Cuánto se tarda en contratar y ejecutar un pentesting?

Desde el primer contacto a la entrega del informe final, el ciclo típico es 4-8 semanas: 1-2 semanas de scoping y propuesta, 1 semana de planificación y kick-off, 1-3 semanas de ejecución según alcance y 1 semana de informe y debrief. Si necesitas el informe para una fecha concreta (auditoría, release), avisa al proveedor en el primer correo para confirmar disponibilidad del equipo.

¿Cuándo conviene cambiar de proveedor de pentesting?

Cuando los informes traen los mismos hallazgos año tras año sin que el alcance haya cambiado, cuando el equipo asignado rota cada año y se pierde el contexto, o cuando el proveedor empieza a vender más servicios adyacentes (formación, consultoría) que la propia auditoría. Un cambio cada 2-3 años es razonable para refrescar el ojo crítico, sin convertirlo en política.

¿Debo facilitar credenciales o código fuente al proveedor?

En la mayoría de los casos sí. Una prueba de caja gris con credenciales de cada rol cubre más superficie por hora que una de caja negra, porque el equipo no gasta jornadas en obtener acceso y puede centrarse en autorización, lógica de negocio y flujos internos. La caja blanca (código y arquitectura) compensa en módulos críticos como autenticación, pagos o criptografía. La caja negra tiene sentido cuando el objetivo es medir exactamente lo que ve un atacante externo sin información previa. El detalle está en diferencias entre auditoría de caja blanca, negra y gris. Un proveedor serio te propone la modalidad en función del objetivo, no de lo que le resulta más cómodo.

¿Hace falta certificación específica para auditar?

OSCP es el referente histórico para pentesting práctico. OSWE para web avanzado, OSEP para evasión, CRTO para red team. Para apps móviles, certificaciones específicas como OSMR son menos frecuentes y la huella en advisories pesa más. Para TLPT (DORA), TIBER-EU exige proveedores acreditados por el ECB o por el banco central correspondiente. Las certificaciones son señal pero no garantía.

¿El informe debe ir firmado por una persona concreta?

Sí. El informe técnico se firma por el equipo que ejecutó la prueba (no la empresa abstracta) y suele incluir el responsable técnico del proyecto. Esa firma es lo que un auditor externo reconoce como evidencia de que el trabajo lo hizo un profesional identificable.

¿Qué hago si los hallazgos del pentesting son demasiados para arreglar?

Priorizar por riesgo real (probabilidad de explotación + impacto de negocio), no por severidad CVSS aislada. Atacar primero los hallazgos críticos en superficies expuestas a Internet, después los críticos en superficies internas, después los altos por categoría (autenticación, autorización, criptografía) y dejar los medios y bajos para el siguiente ciclo. El proveedor serio te ayuda a priorizar; el flojo deja la lista plana y se va.

Recursos relacionados

• Qué es un pentesting: el pillar del cluster, con metodología y comparativas con red team y bug bounty.
• Pentesting de aplicaciones web: qué cubre concretamente la auditoría web y cómo encaja con OWASP Top 10.
• Pentesting de APIs REST y GraphQL: la auditoría del backend y las peculiaridades respecto al pentesting web tradicional.
• Pentesting móvil iOS y Android: qué pide MASVS/MASTG y cómo difieren las auditorías iOS y Android.
• Diferencias entre auditoría caja blanca, negra y gris: qué profundidad pedir según el escenario.
• Empresas de ciberseguridad en España: cómo elegir: tipos de proveedor, catálogo de servicios y especialización por sector cuando la decisión va más allá del pentesting.
• Cuánto cuesta un pentesting en España: rangos orientativos por tipo de activo y cómo leer una propuesta económica.

Cómo trabajamos en Secra

Aplicamos a nuestras propias propuestas los criterios de esta guía: scoping técnico antes de cotizar, equipo nominado en la propuesta, informe de muestra anonimizado bajo NDA, metodología explícita (OWASP WSTG y MASTG, API Security Top 10, PTES, NIST SP 800-115) y retest incluido. Nuestro programa de investigación ha publicado advisories en NVD e INCIBE-CERT, entre ellos CVE-2025-40652 y CVE-2023-3512. Si quieres una propuesta para un alcance concreto, escríbenos a través de contacto o consulta el detalle de auditoría web y móvil, auditoría de infraestructura y auditoría cloud.