Un pentest (penetration test, o prueba de penetración) es una intrusión autorizada a tu propia infraestructura. Un equipo externo intenta entrar con las mismas técnicas que usaría un atacante real, documenta cómo lo logró y te entrega el camino completo para que puedas cerrarlo.
La palabra clave es autorizada. Todo lo demás se parece bastante a un ataque, y esa es exactamente la idea: si el ejercicio no incomoda, no está midiendo nada.
Un escaneo no es un pentest
Es la confusión más cara del mercado, porque las dos cosas se cotizan como si fueran lo mismo y no se parecen.
Un escáner de vulnerabilidades compara tu superficie contra una base de datos de fallas conocidas y te devuelve una lista. Es automático, rápido y barato. También devuelve falsos positivos, no entiende tu lógica de negocio y no sabe encadenar dos fallas menores para convertirlas en una crítica.
Un pentest empieza donde el escáner termina. Un especialista toma esos candidatos, descarta el ruido, y explota los que sí son reales para demostrar hasta dónde llega el daño. La diferencia no está en la herramienta: está en que alguien con criterio decide qué vale la pena perseguir.
Un escáner te dice qué puertas están abiertas. Un pentest te dice qué hay adentro y qué se puede sacar.
Qué se evalúa
La superficie depende de tu organización, y el alcance se define contigo antes de empezar. Un ejercicio puede cubrir aplicaciones web, aplicaciones móviles, APIs, infraestructura interna y perimetral, entornos de nube, redes inalámbricas, contenedores, dispositivos IoT o industriales, e incluso modelos de inteligencia artificial expuestos.
Lo que importa no es cuántos vectores se listan en la propuesta, sino que se cubra el marco completo del que se evalúe. Una evaluación web seria recorre todo el OWASP Testing Guide, no sólo los tres hallazgos más famosos.
Cómo se ejecuta
Un ejercicio serio sigue una metodología reconocida, y la ejecución técnica se sustenta en estándares como NIST SP 800-115 o PTES. Las fases, en el orden en que ocurren:
- Alcance y reglas de enfrentamiento. Qué entra, qué queda fuera, en qué ventana se ejecuta y quién puede detener el ejercicio. Nada empieza sin autorización por escrito.
- Reconocimiento. Se mapea tu superficie real, que casi siempre es más grande de lo que el inventario dice.
- Modelado de amenazas. Qué adversario tiene sentido para tu industria y qué buscaría primero.
- Análisis de vulnerabilidades. Cobertura amplia con automatización y verificación manual de cada candidato.
- Explotación controlada. Se confirma el riesgo explotándolo, con prueba de concepto funcional y sin afectar tu operación.
- Post-explotación. Hasta dónde llega quien ya entró: movimiento lateral, escalamiento de privilegios y alcance sobre datos críticos.
Ese último paso es el que convierte un hallazgo técnico en una conversación de negocio. “Hay una inyección SQL” mueve a un desarrollador. “Con esa inyección llegamos a la base de clientes completa en once minutos” mueve a un consejo.
Qué recibes
El entregable es lo que separa un buen ejercicio de una factura cara. Debe incluir, como mínimo:
- Reporte técnico con cada hallazgo, su evidencia y su prueba de concepto.
- Resumen ejecutivo que traduzca el riesgo técnico a impacto en el negocio.
- Priorización por severidad, con contexto de tu operación y no sólo un número de CVSS.
- Plan de remediación que tu equipo pueda ejecutar sin acompañamiento.
- Retest que verifique que lo corregido quedó cerrado.
Y una prueba de calidad simple: si tu equipo de desarrollo no puede reproducir un hallazgo leyendo el reporte, ese reporte está mal escrito.
Caja negra, gris y blanca
Los tres nombres se refieren a cuánta información recibe el equipo ofensivo antes de empezar.
| Modalidad | Qué sabe el equipo | Para qué sirve |
|---|---|---|
| Caja negra | Nada, sólo el objetivo | Simula al atacante externo sin acceso previo |
| Caja gris | Credenciales de usuario estándar | Mide qué puede hacer alguien que ya entró, o un empleado |
| Caja blanca | Código fuente, arquitectura, credenciales | Máxima cobertura por hora invertida |
La caja negra es la más realista de las tres, pero la caja blanca suele encontrar más. No son niveles de calidad: son preguntas distintas.
Cuándo lo necesitas
Hay cuatro momentos en los que un pentest deja de ser opcional:
- Antes de salir a producción con algo que maneje dinero o datos de terceros.
- Cuando el regulador lo pide, o cuando un cliente grande lo exige en su proceso de proveedores.
- Después de un cambio estructural: una migración a la nube, una fusión, un rediseño de la arquitectura.
- De forma recurrente, si tu superficie cambia todo el año.
Ese último punto es el que más se subestima. El informe de IBM mide que una organización tarda en promedio 241 días en detectar y contener una brecha (IBM, Cost of a Data Breach 2025), y que el costo promedio de un incidente en América Latina llegó a 82 millones de pesos (IBM, 2026). Con esos números, una foto anual deja once meses sin cobertura.
Qué te llevas
Un pentest bien hecho no te entrega una lista de vulnerabilidades. Te entrega una respuesta a la pregunta que de verdad importa: si alguien quisiera entrar hoy, ¿por dónde lo haría y hasta dónde llegaría?
Si vas a contratar uno, tres preguntas que separan al proveedor serio del que vende escaneos con otro nombre:
- ¿Qué metodología siguen y qué marco cubren?
- ¿Cada hallazgo viene con prueba de concepto reproducible?
- ¿El retest está incluido o se cotiza aparte?
Si quieres ver cómo lo ejecutamos nosotros, está detallado en nuestro servicio de pentesting. Y si prefieres empezar por lo más simple, cuéntanos qué tienes expuesto y te decimos por dónde entraría alguien.