Auditoría de pentesting: qué es y qué pasa desde la firma hasta el informe

Una auditoría de pentesting es un ataque controlado contra tus sistemas, hecho a mano, con tu autorización por escrito y dentro de una ventana pactada, para averiguar por dónde entraría alguien antes de que entre de verdad.
Lo que casi nunca se cuenta es la otra mitad: cuántos días son, qué te va a pedir el auditor, qué firmas antes de empezar y qué hay dentro del sobre al final. Eso es lo que decide si el proyecto cabe en tu trimestre, así que va todo aquí, con las duraciones de cada fase.
Qué es una auditoría de pentesting
El NIST, en la guía técnica de pruebas y evaluación de seguridad SP 800-115, define el test de intrusión como una prueba en la que los evaluadores simulan ataques reales para encontrar formas de saltarse los controles de una aplicación, un sistema o una red. La palabra que lo cambia todo es «simulan»: hay explotación, no solo detección.
Esa es la línea entre auditar y revisar papeles. Una revisión documental comprueba que exista una política de contraseñas. Un pentest coge una contraseña que se repite en tres servidores y llega hasta el controlador de dominio con ella. El primero te dice que el control existe. El segundo, si aguanta.
Lo que compras, al final, no es el ataque. Es el mapa que sale de él: qué se rompió, en qué orden, con qué evidencia y qué hay que tocar primero.
En qué se diferencia de un escaneo de vulnerabilidades
Un escaneo compara lo que tienes contra una base de datos de fallos conocidos y devuelve una lista. Una auditoría de pentesting coge esa lista como punto de partida, comprueba cuáles son ciertas y encadena las que por separado no valen nada. Son dos trabajos distintos y los dos hacen falta.
| Criterio | Escaneo de vulnerabilidades | Auditoría de pentesting |
|---|---|---|
| Quién lo ejecuta | Una herramienta, sin nadie delante | Un auditor, con la herramienta como punto de partida |
| Qué encuentra | Versiones sin parchear y configuraciones conocidas | Además, la lógica de negocio rota y los permisos que no deberían existir |
| Falsos positivos | Los devuelve sin comprobar | Se descartan probando: lo que llega al informe está explotado o razonado |
| Encadenar fallos | No | Sí, y ahí está casi todo el riesgo real |
| Cuándo se hace | Continuo o mensual | Al menos una vez al año y tras cada cambio grande |
El ejemplo de siempre: un usuario de pruebas olvidado y un formulario que acepta el identificador de otro cliente. Un escáner no marca ninguno de los dos, porque ninguno es una vulnerabilidad de catálogo. Juntos son una lectura completa de la base de datos de facturación.
Que la vía de entrada sea técnica dejó de ser la excepción. El Data Breach Investigations Report de Verizon, en su edición de 2026, sitúa las vulnerabilidades de software como origen del 31 % de las brechas, por delante ya de las credenciales robadas.

Caja negra, gris y blanca: cuál pedir
La diferencia entre las tres es cuánta información recibe el auditor antes de empezar: nada, unas credenciales de usuario normal, o el código y la documentación. Cuanta menos recibe, más días se le van en averiguar lo que tú ya sabes. Y esos días los pagas igual.
- › Caja negra. El auditor empieza con lo mismo que un atacante de internet: un dominio. Sirve para medir qué se ve desde fuera.
- › Caja gris. Entra con credenciales de usuario normal. Es la que pide casi todo el mundo, porque la mayoría de los fallos graves de una aplicación están detrás del login.
- › Caja blanca. Con código, arquitectura y accesos. La cobertura es la máxima posible por día de trabajo.
Si tienes que elegir sin más contexto, elige gris. La caja negra cuesta más y encuentra menos, y solo compensa cuando lo que quieres medir es precisamente qué se ve desde fuera. El desglose de por qué el mismo encargo se cotiza con el triple de diferencia está en la guía de cuánto cuesta un pentesting.
Qué se firma antes de empezar
Tres documentos, y ninguno es un trámite: el acuerdo de confidencialidad, el alcance por escrito con la lista exacta de activos, y la autorización para atacarlos dentro de una ventana con fecha y hora. Sin el tercero, la prueba no se lanza.
El NIST llama a esto reglas de compromiso y las define como las directrices y restricciones detalladas sobre la ejecución de la prueba, establecidas antes de empezar, que dan al equipo autoridad para hacer las actividades definidas sin pedir permisos adicionales. Traducido: evita la llamada de las once de la noche preguntando si el tráfico raro somos nosotros.
El alcance es donde se decide la mitad del resultado, y donde más se equivoca todo el mundo. Se audita lo que está en la lista, y lo que no está en la lista no se mira: el portal que se publicó en marzo y que nadie añadió al inventario se queda fuera aunque sea el que tiene el problema. Por eso una auditoría de superficie externa desde 450 € es un buen primer encargo cuando el inventario no está claro: primero se sabe qué hay expuesto y después se decide qué se audita a fondo.

Las seis fases, con lo que dura cada una
Una auditoría de Pentesting Team tiene seis fases, y cada una termina con un documento que se te queda. Estas son, con su duración y su entregable.
| Fase | Cuánto lleva | Qué se entrega |
|---|---|---|
| Kick-off | 30 minutos | Alcance, objetivos y accesos acordados |
| Plan de auditoría | 1 día | Documento formal con metodología, calendario y matriz de comunicación |
| Auditoría | 1 a 3 semanas | El trabajo de campo, sin cortar tu operación |
| Informe técnico | 1 a 3 días | Cada vulnerabilidad con su evidencia, su criticidad y su remediación |
| Presentación | 30 minutos | Informe ejecutivo y la presentación que usamos en la reunión |
| Retest | 1 a 2 días | Informe nuevo con lo corregido y lo que sigue abierto |
La fase larga es la tercera, y ahí es donde conviene preguntar cómo se trabaja. Auditamos a mano contra referencias públicas: la OWASP Web Security Testing Guide en aplicación web, PTES y OSSTMM en el resto. La herramienta automática corre el primer día y a partir de ahí el trabajo es manual, que es lo que permite encadenar dos fallos menores hasta convertirlos en uno grave. Vale igual para un pentesting de aplicaciones web que para una revisión de la red interna.
Aquí aparece la pregunta razonable: por qué encargarlo fuera si el proveedor que administra tus sistemas ya conoce la casa. Por el incentivo. Quien ha configurado la red tiene que demostrar que está bien configurada, y el encargo de un auditor externo es el contrario. Por eso el plan de auditoría lleva las pruebas previstas por escrito y cada hallazgo del informe trae los pasos para reproducirlo: tu equipo, o tu proveedor, lo comprueban sin llamarnos.
Ese plan es el documento que más se echa de menos cuando no existe. Fija el calendario día a día, el equipo que trabaja y a quién se llama si algo se tuerce, de los dos lados. Se firma antes de tocar nada.
Qué hace falta de tu equipo, y cuándo
Poco, pero concentrado al principio. Lo que alarga una auditoría casi nunca es la técnica: son los accesos que llegan el jueves de la primera semana. Esto es lo que se pide y en qué momento.
- › Antes del kick-off. La lista de dominios, rangos IP y aplicaciones que entran, y quién es el dueño de cada uno.
- › El día del kick-off. Un usuario de pruebas por cada rol distinto de la aplicación. Si hay administrador, gestor y cliente, son tres.
- › Antes de empezar las pruebas. Aviso al proveedor de hosting y a quien gestione el WAF, con las IP desde las que atacamos y la ventana. Si no, el bloqueo llega a la segunda hora.
- › Durante. Una persona localizable por teléfono. Media hora en total, casi siempre cero.
- › En la presentación. Quien decide el presupuesto de corrección, no solo el equipo técnico.
El punto del WAF se salta más de lo que parece y cuesta días. Si el cortafuegos de aplicación bloquea al auditor en la primera hora, lo que mides no es tu aplicación: es tu WAF.

Qué te entregan y quién sabe leerlo
Al terminar se entregan cuatro cosas: el informe técnico con cada hallazgo y su evidencia, el informe ejecutivo con el riesgo en términos de negocio, la presentación de resultados en directo y el retest cuando hayas corregido. El PowerPoint que usamos en esa reunión se entrega también, para quien no estuvo.
Los informes son dos porque son dos lectores. Quien va a corregir necesita la petición exacta que rompió la aplicación. Quien firma el presupuesto necesita saber qué pasa si no se corrige y cuánto cuesta cerrarlo. Un solo documento para los dos acaba siendo demasiado técnico para uno y demasiado vago para el otro.
El retest se puede pedir hasta seis meses después de la entrega y va incluido: volvemos a probar lo que has corregido y sale un informe nuevo que dice qué se cerró y qué sigue abierto. Ese informe es el que enseñas a un cliente o a un certificador, porque un informe con quince hallazgos abiertos no demuestra lo mismo que uno que dice que trece están cerrados. Qué apartados debe traer y cómo se lee cada uno está en la guía del informe de pentesting.
Qué no vas a recibir, y qué no deberías pagar
Una auditoría de pentesting no certifica nada. No existe un sello que salga de aquí, y quien lo ofrezca está vendiendo otra cosa. Lo que sale es un informe con fecha, que sirve como evidencia ante un auditor de ISO 27001 o del ENS, y que vale mientras el sistema siga siendo el que se probó.
Tres cosas que no merece la pena pagar. Un informe que es la salida de una herramienta con membrete: se reconoce porque todos los hallazgos tienen la misma redacción y ninguno trae los pasos para reproducirlo. Un retest facturado aparte cuando el trabajo era nuestro. Y una caja negra contra una aplicación cuando lo que te preocupa está detrás del login, que es pagar días de reconocimiento para llegar a la puerta.
Tampoco vas a recibir una lista de veinte hallazgos críticos. Si un informe los tiene, o el sistema está muy mal o las criticidades están infladas, y lo segundo pasa más. Lo que no merece la pena arreglar lo decimos, y va por escrito en el propio informe.
Cuánto dura de verdad, de la firma al informe
En un alcance acotado, una aplicación con tres roles o un perímetro de pocos dominios, pasan unos diez días entre el kick-off y el informe técnico en la mesa. Cuando el alcance crece, la fase de campo sola se va a tres semanas y el total ronda el mes.
Lo que mueve esa cifra es el número de activos y de roles de usuario, no la dificultad. Dos aplicaciones parecidas con uno y con seis roles no se auditan en el mismo tiempo, porque cada rol multiplica las combinaciones de permisos que hay que probar.
Y antes de todo eso está el presupuesto, que sale en menos de 24 horas laborables con el alcance cerrado. Los precios de partida están publicados por tipo: 450 € una auditoría de superficie externa, 1.140 € una de aplicación web y 1.520 € una de infraestructura interna.
Cada cuánto se repite es otra pregunta, y la respuesta corta es que el informe caduca cuando el sistema cambia, no cuando pasa un año. Lo largo, con los cambios que obligan a repetir antes de tiempo, está en cada cuánto hacer un pentest.
Si vas a encargar el primero, empieza el lunes por el inventario: abre una hoja y escribe los dominios, las IP públicas y las aplicaciones con login que tenéis. Si esa hoja se queda a medias, ya sabes por dónde empezar, y no es por la aplicación. Con esa lista, el presupuesto es una conversación de media hora.
Fuentes
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Pentesting de aplicaciones web · Pentesting manual de tu aplicación web contra OWASP WSTG: la lógica de negocio rota y los accesos que no deberían existir.
- ›Auditoría de superficie externa · Auditoría de todo lo que expones a Internet: subdominios que nadie recuerda, servicios abiertos y credenciales filtradas en brechas ajenas.
- ›Auditoría de infraestructura interna · Pentesting desde dentro de tu red, como quien ya ha entrado: movimiento lateral, escalada de privilegios y hasta dónde se llega en el dominio.
- ›Pentesting de aplicaciones móviles · Pentesting de tu app iOS o Android contra OWASP MASTG: qué guarda en el dispositivo, qué manda por la red y con qué permisos.
- ›Pentesting de APIs · Pentesting de tus APIs REST y GraphQL con el OWASP API Top 10, empezando por la autorización a nivel de objeto.