Pruebas de penetración para empresas: qué esperar de un buen proveedor

Una prueba de penetración es un ataque simulado y autorizado que revela las vulnerabilidades reales de sus sistemas antes de que lo haga un atacante. El resultado inmediato es una lista de fallos priorizados por riesgo y un plan de remediación concreto. Para la empresa, esto significa evidencia objetiva para justificar inversiones en seguridad ante la dirección y una reducción medible de la exposición a incidentes.

En resumen:

• Los pentests ayudan a identificar vulnerabilidades explotables antes que los atacantes y a priorizar correcciones según su impacto real en la empresa.
• La elección del tipo de prueba (caja negra, gris o blanca) depende del conocimiento previo del sistema y del objetivo, afectando el nivel de profundidad y realismo.
• Un informe de calidad debe incluir evidencia técnica reproducible, priorización, plan de remediación y garantías de confidencialidad.
• Los costos varían según el alcance, número de activos y profundidad, siendo recomendable en pymes combinar análisis automatizados con pentests manuales selectivos.
• En sectores regulados, los ejercicios TLPT con enfoque de amenaza avanzada son necesarios para cumplir con requisitos de supervisores como DORA y TIBER-EU.

Qué son las pruebas de penetración y por qué importan en un programa de seguridad

Una prueba de penetración, o pentest, consiste en intentar comprometer sistemas, aplicaciones o redes de forma controlada, con el mismo enfoque que usaría un atacante real, pero bajo un acuerdo formal y límites definidos. El objetivo no es solo encontrar fallos técnicos, sino demostrar su impacto real: qué podría robar, modificar o paralizar alguien que los explotara.

Conviene distinguir el pentest de otras prácticas con las que a menudo se confunde. Un análisis SAST revisa el código fuente en busca de patrones inseguros antes de compilar la aplicación. Un análisis DAST examina la aplicación ya en ejecución, simulando peticiones maliciosas desde fuera. Ambos son automáticos, rápidos y baratos de repetir, pero tienen un límite claro: no razonan como una persona, así que pasan por alto errores de lógica de negocio, cadenas de vulnerabilidades combinadas o fallos de configuración específicos del entorno.

Por eso la guía OWASP WSTG recomienda combinar herramientas automáticas con validación manual: las primeras aportan cobertura amplia, la segunda aporta el criterio humano que detecta lo que un escáner no entiende. Un pentest bien ejecutado no sustituye los controles continuos (parcheo, monitorización, gestión de identidades); los complementa con una fotografía puntual y profunda del estado real de la seguridad.

Los beneficios concretos para una empresa incluyen:

• Detectar vulnerabilidades explotables antes que un atacante, no solo teóricas.
• Obtener una prioridad clara de qué corregir primero según el impacto real en el negocio.
• Generar evidencia documental útil para auditorías, seguros de ciberriesgo o clientes que exigen garantías contractuales.
• Validar si los controles de seguridad ya implementados funcionan bajo presión real.

La limitación honesta es que un pentest es una foto fija: refleja el estado de los sistemas en el momento de la prueba, no una garantía permanente. Un cambio de configuración la semana siguiente puede reabrir una brecha ya cerrada.

Tipos de pruebas: caja negra, gris, blanca y otras variantes según el objetivo

No todas las pruebas de penetración se ejecutan igual, y elegir el tipo equivocado desperdicia presupuesto sin responder la pregunta que la empresa necesita resolver.

La clasificación clásica se basa en cuánta información recibe el equipo probador antes de empezar:

• Caja negra: el probador no recibe información previa, igual que un atacante externo. Simula un ataque real desde cero, pero puede tardar más en encontrar fallos profundos.
• Caja gris: el probador recibe credenciales básicas o documentación parcial, como un usuario normal de la aplicación. Es el equilibrio más habitual entre realismo y eficiencia.
• Caja blanca: el probador tiene acceso completo a código fuente, arquitectura y credenciales. Permite una cobertura mucho más profunda, ideal antes de lanzar una aplicación crítica.

El red teaming va un paso más allá del pentest tradicional: no busca solo vulnerabilidades técnicas, sino probar si la organización detecta y responde a un ataque prolongado y sigiloso, imitando tácticas de grupos reales de amenaza. Mientras un pentest suele durar días, un ejercicio de red team puede extenderse semanas y pone a prueba también a las personas y los procesos de respuesta.

El modelo PTaaS (pruebas de penetración como servicio) cambia la forma de contratar: en lugar de un informe puntual una vez al año, la empresa accede a una plataforma con pruebas más frecuentes, retesting ágil y visibilidad continua sobre el estado de las vulnerabilidades. Encaja bien con empresas que despliegan cambios en sus aplicaciones con frecuencia, donde un ejercicio anual queda desactualizado en semanas.

Según la superficie evaluada, las pruebas también se especializan: aplicaciones web y APIs, infraestructura de red interna y externa, entornos cloud, dispositivos IoT y pruebas de ingeniería social que miden si el personal cae en intentos de phishing dirigido.

Cómo se desarrolla una prueba de penetración de principio a fin

Un proveedor serio sigue un proceso estructurado, no una improvisación técnica. Conocer las fases ayuda a la empresa a saber qué exigir en cada momento y detectar si un proveedor se salta pasos críticos.

1. Iniciación y alcance: se define qué sistemas se prueban, qué queda fuera, los activos críticos a proteger y las llamadas rules of engagement: horarios permitidos, contactos de emergencia y límites legales. Esta fase determina si el ejercicio tendrá valor real o solo cubrirá el expediente.
2. Reconocimiento e inteligencia: el equipo recopila información pública y técnica sobre la organización, como dominios expuestos, tecnologías usadas y posibles puntos de entrada, tal como haría un atacante antes de actuar.
3. Explotación controlada: se intentan validar las vulnerabilidades identificadas mediante ataques reales pero contenidos, confirmando que un fallo teórico es efectivamente explotable y no un falso positivo del escáner.
4. Escalada y persistencia (cuando aplica): si el acceso inicial lo permite, se comprueba hasta dónde podría llegar un atacante real, como escalar privilegios o moverse a otros sistemas, siempre dentro de los límites acordados.
5. Reporte y remediación: se entrega un informe técnico y otro ejecutivo, con hallazgos priorizados y recomendaciones concretas.
6. Retesting: una vez aplicadas las correcciones, se vuelve a probar lo corregido para confirmar que el fallo realmente desapareció.

Consejo profesional: pida siempre que el retesting esté incluido o presupuestado por separado desde el inicio. Muchas propuestas económicas omiten esta fase, y sin ella nunca sabrá si sus correcciones funcionaron de verdad.

Durante la explotación, un proveedor riguroso gestiona el riesgo activamente: evita pruebas destructivas en sistemas de producción sin autorización expresa, mantiene comunicación constante con un contacto técnico interno y detiene la prueba de inmediato si detecta un riesgo real de caída del servicio.

Qué entregables y evidencia debe incluir un informe de pentest

El valor de una prueba de penetración se juzga por la calidad de su informe, no solo por el número de vulnerabilidades encontradas. Un informe débil enumera fallos sin contexto; uno bueno permite actuar el mismo día que se recibe.

Los elementos que debe exigir en cualquier propuesta son:

• Resumen ejecutivo en lenguaje de negocio, que traduce hallazgos técnicos en riesgo real para la operación, sin jerga innecesaria.
• Evidencia técnica reproducible: capturas de pantalla, registros (logs) y pruebas de concepto que permitan a su equipo interno verificar el hallazgo por sí mismo, no solo confiar en la palabra del probador.
• Priorización por impacto y facilidad de corrección, para saber qué arreglar primero cuando los recursos son limitados.
• Plan de remediación con plazos realistas, indicando responsables y pasos concretos para cada hallazgo.
• Retesting documentado, con constancia de qué se corrigió y qué sigue pendiente.
• Garantías de confidencialidad sobre cómo se almacena, transmite y elimina la información sensible generada durante la prueba, incluidas credenciales o datos de clientes a los que el equipo haya tenido acceso.

La WSTG de OWASP advierte de algo que muchas empresas pasan por alto: superar un pentest sin hallazgos graves no garantiza ausencia de problemas, del mismo modo que un resultado negativo en una prueba puntual no cubre lo que pueda cambiar después. La evidencia y el contexto importan más que un veredicto binario de “aprobado” o “suspendido”.

Cómo elegir un proveedor de pruebas de penetración sin arrepentirse después

Contratar mal un pentest sale caro dos veces: se paga por un informe que no aporta valor y se sigue expuesto a los mismos riesgos. Antes de firmar, verifique estos criterios.

• Alcance bien definido: el proveedor debe preguntar por sus activos críticos, no limitarse a un escaneo genérico de IPs.
• Metodología reconocida: exija que mencionen marcos como OWASP WSTG o metodologías equivalentes, y que expliquen cómo combinan herramientas automáticas con revisión manual.
• Experiencia en su sector: los riesgos de una tienda online, una clínica o una gestoría no son los mismos; pregunte por casos similares al suyo.
• Validación humana real, no solo un informe generado por un escáner automático con el logotipo del proveedor pegado encima.
• Seguridad operacional propia: pregunte cómo protegen ellos mismos las credenciales y evidencias que obtienen de su empresa durante la prueba.

Antes de contratar, plantee estas preguntas directas en la reunión o en la solicitud de propuesta: ¿quién firma y valida el informe final?, ¿tendremos acceso a la evidencia técnica completa, no solo al resumen?, ¿el retesting está incluido o se cobra aparte?, ¿qué plazo de respuesta garantizan ante un hallazgo crítico durante la prueba?

Desconfíe de propuestas con precios muy por debajo del mercado sin explicar el alcance exacto, de contratos que no especifican qué sistemas quedan cubiertos y de proveedores que se niegan a firmar un acuerdo de confidencialidad antes de empezar. Los modelos comerciales más habituales son el proyecto cerrado por alcance definido, la suscripción tipo PTaaS con pruebas recurrentes y los contratos de soporte continuo que incluyen ciclos de pentest periódicos.

Consejo profesional: pida siempre una muestra anonimizada de un informe anterior antes de firmar. Un proveedor serio la tiene lista; uno que improvisa, no.

DORA y TIBER-EU: cuándo un pentest no es suficiente

Para entidades financieras, un pentest convencional puede no bastar. El Reglamento Delegado (UE) 2025/1190, que desarrolla los requisitos técnicos de DORA sobre pruebas de penetración basadas en amenazas (TLPT), define criterios detallados sobre qué entidades están obligadas, con qué alcance y qué separación debe existir entre quien aporta la inteligencia de amenazas y quien ejecuta el ataque simulado.

El marco TIBER-EU del BCE es la referencia operativa para ejecutar estos ejercicios en entidades significativas, y exige equipos de inteligencia de amenazas independientes de los equipos de ataque, además de supervisión directa de los reguladores.

Las diferencias frente a un pentest estándar son notables. Un TLPT no se limita a probar sistemas: simula un ataque real dirigido y prolongado contra la entidad completa, con escenarios diseñados a partir de inteligencia de amenazas específica del sector. Algunos marcos regulatorios sugieren fases activas de al menos doce semanas para lograr el realismo necesario, muy por encima de los días o semanas que dura un pentest convencional.

Aunque el TLPT es obligatorio principalmente para entidades financieras significativas bajo DORA, empresas de otros sectores con alta dependencia digital o proveedores críticos de servicios financieros pueden beneficiarse de adoptar principios similares, aunque a escala reducida. Durante un ejercicio de este tipo, la gestión del riesgo exige protocolos de parada de emergencia, canales de comunicación reservados y control constante por parte de la autoridad competente.

Cuánto cuesta contratar un pentest y de qué depende el precio

El coste de una prueba de penetración varía mucho según el alcance, la profundidad y el tipo de prueba elegida, y no existe una tarifa única aplicable a todas las empresas. Un pentest de caja negra sobre una sola aplicación web sencilla cuesta menos que uno de caja blanca sobre una infraestructura completa con múltiples sistemas interconectados.

Los factores que más influyen en el precio final son el número de activos a evaluar (aplicaciones, servidores, rangos de IP), la profundidad de las credenciales y accesos entregados al equipo probador, el tiempo estimado de trabajo humano necesario, y si se incluye retesting o informe ejecutivo adaptado a dirección. Un ejercicio de red teaming, al ser más largo y complejo, suele costar sensiblemente más que un pentest tradicional de alcance equivalente.

Para una pyme, el enfoque más razonable en coste y beneficio suele combinar análisis automatizados frecuentes y económicos con un pentest manual puntual centrado en los sistemas más críticos, en lugar de intentar cubrirlo todo con presupuesto limitado. Los modelos PTaaS pueden abaratar el coste por ciclo al repartir el trabajo en pruebas más frecuentes y acotadas, frente al gasto concentrado de un único ejercicio anual exhaustivo. Antes de pedir presupuesto, conviene tener claro qué activos son realmente críticos para no pagar por cubrir sistemas de bajo riesgo mientras se descuidan los que de verdad importan.

Casos reales: qué revela un pentest cuando se hace bien

Los ejemplos más ilustrativos de pentesting exitoso no son los que confirman que todo estaba bien, sino los que encuentran algo que nadie esperaba. Una vulnerabilidad de escalada de privilegios en un panel de administración mal configurado, por ejemplo, puede pasar meses sin ser detectada por herramientas automáticas porque requiere encadenar dos fallos menores que, por separado, parecen inofensivos.

En el sector financiero, los ejercicios TLPT bajo el marco TIBER-EU han servido para revelar brechas en la coordinación entre equipos de seguridad y de operaciones durante un incidente simulado, más que fallos puramente técnicos: la entidad detectaba el ataque, pero tardaba demasiado en escalar la respuesta a las personas correctas. Ese tipo de hallazgo organizativo suele tener más impacto real que encontrar un servidor sin parchear.

En empresas de menor tamaño, el patrón habitual es distinto: un pentest de caja gris sobre una aplicación de gestión interna descubre que un empleado con permisos limitados puede acceder a datos de clientes de otros departamentos simplemente modificando un parámetro en la URL, un fallo de control de acceso clásico que ningún escáner automático detecta porque técnicamente la petición es “válida”. Corregirlo cuesta unas horas de desarrollo; no haberlo detectado podría haber costado una filtración de datos con consecuencias legales y reputacionales muy superiores.

Cómo priorizar el pentesting cuando el presupuesto de IT es limitado

Después de años viendo cómo pymes abordan la seguridad, la conclusión es sencilla: el error más común no es no hacer pentesting, es hacerlo sin escalonarlo según la madurez real de la empresa. Una empresa que aún no tiene copias de seguridad automatizadas ni control de accesos básico no necesita un red team de varias semanas; necesita un pentest de caja gris centrado en sus tres o cuatro sistemas más críticos.

Lo que debería esperar de un proveedor que actúa como su departamento de sistemas externo es continuidad, no un informe aislado que nadie vuelve a mirar. Eso significa acompañar el pentest con soporte técnico que aplique las correcciones, no solo señalarlas, y con un plan de detección de amenazas que mantenga la vigilancia entre un ejercicio y el siguiente.

El valor no está en el informe más grueso, sino en el que realmente se aplica.

— Sem

Cómo trabaja Kipmion las pruebas de penetración para empresas

Algunos proveedores actúan como un departamento de sistemas externo para su empresa, cubriendo desde la consultoría de seguridad hasta la implementación de correcciones y el retesting posterior, evitando así la necesidad de coordinar varios proveedores para cerrar un ciclo de seguridad.

Muchas pymes contratan un pentest puntual y luego no saben quién debe aplicar las correcciones ni verificar que funcionaron. Kipmion evita esa desconexión: el mismo equipo que revisa su seguridad de la información puede acompañar la remediación con soporte informático profesional y sistemas de comunicación adaptados a lo que su infraestructura realmente necesita. El proceso mínimo de contratación empieza con una conversación sobre los activos críticos y el nivel de madurez actual, para ajustar el alcance a las necesidades reales.

Si busca una revisión completa de sus vulnerabilidades y un plan de remediación que alguien vaya a ejecutar de verdad, puede solicitar presupuesto a través de la página de servicios de soporte informático de Kipmion y describir el alcance de sus sistemas para recibir una propuesta ajustada a su empresa.

Fuentes

Para profundizar en los aspectos regulatorios y técnicos tratados, estas son las referencias primarias más relevantes. El Reglamento Delegado (UE) 2025/1190 detalla los requisitos técnicos de DORA sobre TLPT. La guía TIBER-EU del BCE explica cómo se ejecutan estos ejercicios en la práctica supervisora europea. La OWASP WSTG sigue siendo la referencia técnica más completa para metodología de pruebas. La guía de CREST sobre TLPT en servicios financieros y los recursos de INCIBE sobre la profesión de pentester completan el panorama con perspectiva nacional.

• Reglamento Delegado (UE) 2025/1190 (DORA – RTS TLPT)
• Threat-led penetration testing guidance (ECB / TIBER-EU)
• OWASP Web Security Testing Guide (WSTG)

Preguntas frecuentes

¿Qué es exactamente una prueba de penetración?

Es un ataque simulado y autorizado contra sistemas, aplicaciones o redes de una empresa, ejecutado por profesionales para descubrir vulnerabilidades explotables antes de que lo haga un atacante real. El resultado es un informe con hallazgos priorizados y un plan de corrección.

¿Cuáles son las principales metodologías de pruebas de penetración?

Las metodologías más citadas incluyen la OWASP WSTG para aplicaciones web, y marcos específicos como TIBER-EU para el sector financiero bajo DORA. Todas comparten fases similares: reconocimiento, explotación controlada y reporte.

¿Qué son las pruebas SAST y DAST?

SAST analiza el código fuente de una aplicación en busca de patrones inseguros antes de que se ejecute. DAST prueba la aplicación ya en funcionamiento, simulando ataques externos reales. Ambas son automáticas y complementan, pero no sustituyen, un pentest manual.

¿Qué ocurre en la primera fase de una prueba de penetración?

La primera fase es la iniciación: se define el alcance exacto, los activos críticos a proteger y las reglas del ejercicio, conocidas como rules of engagement. Sin esta fase bien definida, el resto de la prueba pierde precisión y valor real.

¿Cada cuánto debe una empresa repetir un pentest?

No existe una frecuencia universal, pero un ciclo de entre seis y doce meses es razonable para la mayoría de pymes, ajustándolo según cuántos cambios sufran sus sistemas. Las entidades financieras bajo DORA siguen calendarios específicos para sus pruebas TLPT marcados por el regulador.

Recomendaciones

• Cómo auditar infraestructura TI: guía práctica para pymes
• Protección de datos en empresas: guía práctica para pymes
• Protege tu pyme en 90 días: seguridad de puntos finales por criticidad
• Fortalecer la seguridad de red en tu pyme: clave en 2026