Siete fases, en el orden en que las recorremos. Qué necesitamos de ti antes del primer día, qué pasa en cada fase, qué acaba en tu mesa al final y qué cosas un pentest no te va a contar.
Todos los proyectos que hacemos recorren las mismas siete fases, sea cual sea el objetivo. Una API de pagos, un clúster de Kubernetes y un dominio de Active Directory se prueban con herramientas distintas, pero la secuencia no cambia: acordar el alcance y las reglas, dibujar la superficie, deducir a qué iría un atacante de verdad, encontrar las vulnerabilidades, demostrarlas, informar y volver a comprobar la corrección.
Esa secuencia no es nuestra. Es la forma del Penetration Testing Execution Standard, cuyos siete apartados van de las interacciones previas al encargo hasta el informe, y la de la SP 800-115 de NIST, que agrupa el mismo trabajo en planificación, descubrimiento, ataque e informe, con un bucle de realimentación que vuelve del ataque al descubrimiento cada vez que un punto de apoyo abre terreno nuevo.
La puerta de entrada ha cambiado. El Data Breach Investigations Report 2026 de Verizon, que cubre incidentes entre el 1 de noviembre de 2024 y el 31 de octubre de 2025, encontró que el 31% de las brechas empiezan ya por la explotación de una vulnerabilidad de software, por delante de las contraseñas robadas.
No se envía nada hasta que el alcance y las rules of engagement están acordados por escrito. El alcance nombra los sistemas, los entornos y las identidades que entran. Las reglas cubren el resto: la ventana de pruebas, las direcciones desde las que sale nuestro tráfico, hasta dónde puede llegar la explotación y qué pasa si encontramos indicios de que alguien llegó antes que nosotros.
NIST publica una plantilla de rules of engagement en el anexo B de la SP 800-115, y la guía del PCI Security Standards Council plantea las mismas preguntas. Por nuestra experiencia, esta es la parte que se hace mal.
Acordamos también los criterios de finalización, el punto en el que el test se da por terminado. La guía de PCI es directa: definirlos es lo que fija la profundidad del test, y sin ellos quien prueba puede pasarse de las fronteras que esperabas.
El reconocimiento es la primera fase en la que se envía algo. Construimos la imagen que construye un atacante antes de elegir puerta: equipos y direcciones, servicios y puertos expuestos, huellas de tecnología, endpoints y parámetros, identidades y las fronteras entre roles. NIST pone esto al principio de su fase de descubrimiento, antes de cualquier análisis de vulnerabilidades, y sus técnicas siguen en uso diario, del interrogatorio de DNS a la lectura de banners.
En trabajo externo es aquí donde viven las sorpresas: el equipo que no es de nadie, la copia de preproducción que responde a internet, el subdominio que apunta a un servicio apagado hace dos años. Cruzamos lo que encontramos con tu propio inventario de activos, porque la diferencia entre esas dos listas ya es un hallazgo.
Entre el reconocimiento y las pruebas paramos a hacer la cuenta: qué escenarios de ataque son realistas aquí, ordenados por probabilidad y por coste. El modelado de amenazas es una fase propia en PTES porque evita que un proyecto se gaste las horas en una lista genérica mientras lo que de verdad haría daño se queda sin probar.
Es también donde la metodología deja de ser genérica. La lista de comprobación sale de la norma que gobierna el objetivo:
La herramienta da cobertura. Las personas dan certeza. Los escáneres corren primero porque son rápidos sobre una superficie grande; después cada candidato se valida a mano. NIST pone el límite sin adornos: un escáner de vulnerabilidades solo comprueba la posible existencia de una vulnerabilidad, mientras que la fase de ataque la explota para confirmar que existe.
Los hallazgos que más importan suelen ser los que ningún escáner tiene fichados. Un fallo de lógica de negocio. Una comprobación de autorización puesta en un endpoint y olvidada en el siguiente. Un flujo que se puede repetir en desorden, o completar sin el paso que cobra.
La explotación es verificación, no espectáculo. La fase de ataque de NIST existe para confirmar una vulnerabilidad sospechada explotándola, y el bucle de vuelta al descubrimiento forma parte del modelo: un exploit que funciona expone superficie nueva, que se analiza y se prueba a su vez. Ese bucle es como los hallazgos sueltos se convierten en cadenas: un salto de directorio que solo lee ficheros deja de ser de severidad baja en el momento en que uno de esos ficheros guarda una credencial.
La postexplotación responde a la pregunta que hará tu comité de dirección: ¿y esto qué implica? Medimos el alcance de un punto de apoyo contra la confidencialidad, la integridad y la disponibilidad, siguiendo los caminos de escalada de privilegios y de movimiento lateral hasta donde permiten las rules of engagement, y ni un paso más. El tramo largo de esos caminos, el que va de un clic en un phishing a la administración del dominio, casi nunca es espectacular: es una sucesión de credenciales reutilizadas y de protocolos de administración que nadie bloqueó.
Una puntuación de severidad no es una cola de trabajo. Lo dice la propia especificación de CVSS v4.0: se espera que quien la consume use CVSS como una entrada de un proceso de gestión de vulnerabilidades que pesa además factores que CVSS no modela. Así que los hallazgos se ordenan con tres señales, no con una.
Por encima de las tres está la señal que no podemos calcular nosotros: cuánto vale el sistema afectado. Una media en el servicio que mueve tu dinero va por delante de una alta en el equipo que sirve las imágenes de marketing.
El informe es el producto. El nuestro sigue la estructura que fija el PCI Security Standards Council, porque es legible a la vez para un evaluador, un auditor y un director de tecnología:
Esos hallazgos aterrizan también en nuestra plataforma, donde cada uno lleva su prueba de concepto y su impacto en el negocio, y donde se sigue la verificación de las correcciones.
Después, el retest. Cuando has remediado, probamos la corrección y o firmamos el hallazgo como cerrado o decimos por qué no lo está. La guía de PCI es precisa: la remediación debería completarse y volverse a probar en un plazo razonable después del informe original, y si se alarga, la respuesta honesta es un proyecto nuevo, porque el entorno se ha movido.
La duración la decide el alcance, no un menú estándar, así que no vamos a poner un número al tuyo en una entrada de blog. Lo que sí podemos decirte es qué lo mueve, porque son las preguntas que hacemos antes de acordar días con nadie.
Dos cosas conviene aclarar antes de comparar un presupuesto con otro. Los días presupuestados de pruebas no son días de calendario: la redacción del informe, tu revisión y el retest van todos después de la última petición enviada.
Y la profundidad está acotada por los criterios de finalización que nombran las rules of engagement, que es la razón de que la guía de PCI trate definirlos como lo que fija la profundidad del test y mantiene a quien prueba dentro de las fronteras que esperabas. NIST dice lo mismo desde el otro lado: un test suele llevar un alcance estrecho por limitaciones de recursos, en particular de tiempo, mientras que un atacante se toma el tiempo que necesite.
Lo que un test no cubre decide si estás comprando lo correcto, así que va en el mismo documento que la metodología y no en una conversación posterior.
La secuencia real de un pentest de red externa: alcance y rules of engagement, reconocimiento, análisis del perímetro, explotación, informe y retest, además de lo que el test no va a cubrir.
La secuencia de un pentest de red interna real: el punto de partida que acordamos, en qué se convierte una cuenta de dominio, qué recibes al final, cuánto dura y qué cosas no cubre el ejercicio a propósito.
La secuencia real de un pentest wifi, de las rules of engagement al retest: qué pasa en cada fase, qué necesitas tener listo, cuánto dura y qué cosas no cubre este test a propósito.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
