Cómo elegir una empresa de pentesting: guía para CISOs y responsables de seguridad

Elegir una empresa de pentesting es una decisión que se toma una vez al año pero condiciona toda la postura de seguridad técnica de una organización: qué bugs se descubren, cuán reproducible es la prueba, cómo se prioriza el remediation y si el informe sirve después delante de un auditor de NIS2, DORA o ISO 27001. La mayoría de RFPs comparan precio y entregables superficiales, pero los hallazgos que cambian la vida de un equipo de seguridad vienen de tres factores que rara vez aparecen en el cuadro comparativo: el perfil técnico real del equipo, la metodología documentada y la calidad del informe que realmente entregan.

Esta guía resume qué buscar al contratar un proveedor de pentesting, las señales de alerta que conviene detectar antes de firmar, los tipos de empresa disponibles (boutique, big four, MDR/MSSP, fabricante con servicio profesional) y las preguntas concretas que separan al equipo serio del que cumple el papel.

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 MASTG para web/móvil, OWASP API Security Top 10 para API, PTES y NIST 800-115 para infra, MITRE ATT&CK para red team. El proveedor debe poder explicar con qué metodología trabaja y mapear cada hallazgo al control 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.

Tipos de empresa de pentesting: cuándo conviene cada una

Cuatro categorías con perfiles muy distintos. Ninguna es "mejor" en abstracto: depende del activo y del momento.

Boutiques especializadas

Equipos de 10 a 100 personas centradas exclusivamente en seguridad ofensiva. Investigación propia, advisories firmados, cero comercial agresivo. Ejemplos en España: Tarlogic, Hispasec, BlackArrow (pentesting), Internet Security Auditors, Securízame y un grupo de boutiques medianas (entre las que nos incluimos en Secra).

Cuándo encajan: aplicación crítica, programa serio, organización que valora la profundidad técnica del informe y el contacto directo con quien hace la prueba. La continuidad año tras año es habitual porque los equipos aprenden el contexto y aceleran cada nuevo ciclo.

Big Four y consultoras grandes

PwC, Deloitte, KPMG, EY tienen división de cyber. Sirven cuando la decisión de compra está en el comité ejecutivo y se valora el sello reputacional, o cuando la auditoría se contrata como parte de un proyecto de compliance más grande (ENS, NIS2, ISO 27001) que el mismo proveedor ya está liderando.

Limitación habitual: el perfil técnico ofensivo dentro de la firma rota mucho, y la profundidad del informe a menudo queda por debajo de una boutique. La mejor versión del Big Four en pentesting es cuando subcontrata a una boutique y firma encima.

MSSP y MDR con servicio profesional

Telefónica Tech, S2 Grupo, Innotec, Indra, GMV ofrecen pentesting como pieza dentro de un programa de servicios gestionados (SOC, EDR, MDR, GRC). Tienen sentido cuando ya consumes su SOC o su servicio gestionado y quieres consolidar proveedor.

Limitación: el pentesting no suele ser el producto core, así que la calidad del entregable depende mucho del equipo concreto asignado y de la prioridad que el proveedor le dé a tu cuenta.

Fabricantes con servicio profesional

Algunos fabricantes (Microsoft, AWS, Cloudflare, Datadog, CrowdStrike) ofrecen servicios profesionales que incluyen pentesting o red team de su propia plataforma. Útiles cuando el activo está dentro de su ecosistema y quieres que la prueba la ejecute quien conoce las internals.

Limitación: tienden a centrarse en el ecosistema propio. Si tu superficie es heterogénea (multi-cloud, múltiples SaaS, infra on-prem), no cubre todo.

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 medidas técnicas demostrada para servicios esenciales. La auditoría debe documentar metodología, alcance representativo y evidencia reproducible. El organismo competente (INCIBE en sectores estatales en España) puede pedir el informe.
• DORA (artículo 24-25). Pruebas técnicas de resiliencia operativa con frecuencia mínima anual y, para entidades significativas, TLPT bajo TIBER-EU cada tres años. El proveedor debe acreditar capacidades específicas para TLPT (intelligence-led, equipo separado del SOC, threat profile validado).
• ISO 27001:2022 (control 8.29). Pruebas de seguridad en el ciclo de vida del software. La auditoría documentada (con metodología, hallazgos, fixes y retest) es evidencia directa para el control.
• PCI DSS v4.0 (req. 11.4). Pentesting interno y externo anual + tras cualquier cambio significativo. El proveedor debe seguir una metodología "industry-accepted" (PTES, OWASP, NIST 800-115) y el equipo debe ser organizativamente independiente del responsable de los activos auditados.

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 3 en horas reales dedicadas.

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.

¿Es mejor una boutique pequeña o una empresa grande?

Depende del activo y de la organización compradora. La boutique aporta profundidad técnica, contacto directo y continuidad. La empresa grande aporta capacidad de cobertura geográfica, integración con otros servicios y sello reputacional. Lo importante no es el tamaño sino el perfil del equipo concreto que ejecuta la prueba: pídelo nominalmente.

¿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.

Cómo trabajamos en Secra

En Secra hacemos pentesting web, móvil, API, infraestructura interna y externa, cloud y red team con OWASP WSTG, MASVS, API Top 10 y PTES, equipo identificable con investigación propia (CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB publicados en NVD e INCIBE-CERT) y entrega informes con prueba de concepto reproducible, severidad CVSS justificada, retest incluido y mapeo a NIS2, DORA, ENS, ISO 27001 o PCI DSS según aplique. Si quieres una propuesta concreta para tu alcance, escríbenos a través de contacto o consulta el detalle de los servicios de auditoría web y móvil, auditoría de infraestructura y auditoría cloud.