¿Cuál es la diferencia entre un pentest y una auditoría de seguridad?
Una auditoría de seguridad revisa configuración, accesos, versiones y procesos contra una lista de controles, y te dice todo lo que está abierto. Un pentest simula un ataque real para probar hasta dónde llega alguien que explota esas fallas. La auditoría busca amplitud; el pentest, profundidad. Se complementan, pero no se sustituyen.
La guía técnica de NIST para pruebas de seguridad, SP 800-115, separa tres familias de técnicas. Las de revisión examinan documentación, registros, reglas de firewall y configuración de sistemas; son pasivas y tienen un riesgo mínimo para la operación. Las de identificación y análisis descubren equipos, puertos y vulnerabilidades. Y las de validación, donde está el pentest, confirman que una falla se puede explotar de verdad.
El pentest es una prueba de seguridad en la que los evaluadores imitan ataques reales para encontrar formas de burlar las funciones de seguridad de una aplicación, un sistema o una red. (NIST SP 800-115, traducción propia)
| Auditoría de seguridad | Pentest | |
|---|---|---|
| Pregunta que responde | ¿Qué tengo abierto y qué falta corregir? | ¿Hasta dónde llega un atacante con lo que hay? |
| Método | Revisión de configuración, accesos, versiones y código contra controles | Ataques controlados con las técnicas de un atacante real |
| Alcance | Amplio: nube, repositorios, código, servidores, procesos | Acotado: los sistemas y reglas que se acuerdan antes |
| Riesgo para la operación | Bajo si es de solo lectura | Mayor: usa ataques reales sobre sistemas reales |
| Entregable | Hallazgos priorizados, plan de corrección y línea base | Informe de fallas explotadas, cadena de ataque y evidencia |
| Frecuencia típica | Continua o periódica | Anual y después de cambios importantes |
| Qué mueve el costo | Cantidad de cuentas, sistemas y servidores | Alcance, horas de especialistas y profundidad de la prueba |
¿Cuándo necesitas cada uno?
Necesitas una auditoría cuando no sabes con certeza qué tienes expuesto: sistemas hechos hace años, una cuenta de nube que nadie ha revisado, accesos de proveedores que ya se fueron. También cuando preparas una auditoría ISO 27001 o respondes un cuestionario de seguridad de un cliente. Es el punto de partida, y en la guía de auditoría de seguridad informática explicamos qué cubre.
Necesitas un pentest cuando un contrato, un cliente o tu industria lo exigen, o cuando ya cerraste lo básico y quieres saber qué haría alguien con experiencia. El caso más claro es el de pagos con tarjeta: el estándar PCI DSS v4 pide, en sus requisitos 11.4.2 y 11.4.3, pentest interno y externo al menos una vez cada 12 meses y después de cualquier cambio significativo de infraestructura o aplicación. Aparte, en el requisito 11.3, pide escaneos de vulnerabilidades cada tres meses. Puedes consultar el texto en la biblioteca del PCI SSC o en este resumen de los requisitos.
¿Por qué corregir lo básico antes del pentest?
Porque el pentest es caro en horas de especialista y conviene gastarlas en lo difícil. NIST lo dice así: el pentest es intensivo en trabajo, requiere mucha experiencia y, por su costo e impacto, hacerlo una vez al año puede ser suficiente; entre pruebas recomienda actividades menos costosas y regulares, como escaneos programados.
Si llegas al pentest con la cuenta raíz sin MFA, el SSH abierto a todo internet, una versión de PHP sin soporte y secretos en el repositorio, el informe se llena de eso. Pagaste a especialistas para encontrar lo que una revisión encuentra en días, y lo interesante (la falla de lógica en tu aplicación, el camino de un usuario normal a administrador) queda sin tiempo. Antes del pentest conviene:
- Cerrar lo que cualquier escáner ve: puertos, versiones, cabeceras, TLS. El chequeo gratis te da un primer dato de tu PHP.
- Revisar accesos: MFA, llaves viejas, usuarios de exempleados.
- Revisar el código contra las fallas del OWASP Top 10: inyección, autenticación, secretos, dependencias.
- Actualizar lo que aparece en las alertas de la semana.
- Tener respaldos probados, por si la prueba afecta un sistema.
Ese último punto no es exageración. NIST advierte que durante un pentest los sistemas pueden dañarse o quedar inoperables, y que aunque un equipo con experiencia reduce el riesgo, nunca lo elimina del todo. Por eso se pacta el alcance, los horarios y un punto de paro antes de empezar.
¿Qué hacer con el informe del pentest?
- Clasificar cada hallazgo por riesgo para tu operación, no solo por la calificación del informe.
- Asignar responsable y fecha a cada corrección.
- Corregir con registro del cambio y forma de revertirlo, para no romper producción.
- Volver a probar. PCI DSS, en el requisito 11.4.4, pide repetir la prueba para verificar las correcciones.
- Guardar la evidencia: qué se encontró, qué se cambió y la prueba de que quedó cerrado.
- Meter lo corregido en la vigilancia continua, para que no se vuelva a abrir con el siguiente cambio.
Para aplicaciones web, la OWASP Web Security Testing Guide es la referencia abierta de cómo se prueba cada área. Sirve para pedirle a tu proveedor de pentest que diga qué metodología usa y qué cubrió.
Así trabaja Security OS, la plataforma de WITS: audita nube, repositorios, código y servidores con acceso de solo lectura, prepara cada corrección con su reversa y la aplica solo con tu autorización. Si empiezas de cero, la guía de ciberseguridad para pymes da el orden de prioridades.
Cuéntanos si tienes un pentest agendado o un informe por corregir. Empezamos con un diagnóstico de solo lectura.
Preparar mi sistema para el pentestPreguntas frecuentes
¿Qué es mejor, un pentest o una auditoría de seguridad?
Ninguno es mejor: responden preguntas distintas. La auditoría te dice todo lo que está abierto; el pentest, hasta dónde llega un atacante. Lo usual es auditar y corregir primero, y después hacer el pentest.
¿Un escaneo de vulnerabilidades es lo mismo que un pentest?
No. El escaneo detecta fallas conocidas de forma automática; el pentest intenta explotarlas y combinarlas como lo haría un atacante. PCI DSS los pide como requisitos separados.
¿Cada cuánto se hace un pentest?
Depende de lo que te exijan. PCI DSS pide pentest interno y externo al menos cada 12 meses y después de cambios significativos. NIST considera que una vez al año puede ser suficiente, con escaneos regulares entre pruebas.
¿Un pentest puede tumbar mis sistemas?
Puede. NIST advierte que los sistemas pueden dañarse durante la prueba y que el riesgo no se elimina del todo. Por eso se acuerdan alcance, horarios y un punto de paro, y conviene tener respaldos probados.
¿Qué debo pedirle a una empresa de pentest?
Alcance por escrito, reglas de la prueba, la metodología que usa, un informe con evidencia de cada falla y una nueva prueba después de que corrijas.
¿WITS hace pentest?
No. WITS no es una empresa de pentest. Preparamos tus sistemas antes de la prueba y corregimos lo que encuentre, con evidencia antes y después. Para la prueba recomendamos una firma especializada e independiente.
¿Una auditoría sustituye al pentest que me pide mi cliente?
No. Si un contrato o un estándar pide pentest, necesitas un pentest. La auditoría hace que llegues a esa prueba con lo básico cerrado.
Fuentes
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- PCI Security Standards Council: PCI DSS v4 (requisitos 11.3 y 11.4)
- Microsoft Learn: texto de los requisitos 11.3 y 11.4 de PCI DSS v4
- OWASP Web Security Testing Guide
- OWASP Top 10
Escrita por Samuel Hinojosa y el equipo de seguridad de WITS · Actualizada el 25 oct 2026 · Markdown
