# Pentest vs. auditoría de seguridad: qué necesita tu empresa y en qué orden

> Diferencias entre un pentest y una auditoría de seguridad: alcance, método, entregable y frecuencia. Cuándo necesitas cada uno y qué hacer con el informe.

Autor: Samuel Hinojosa (CEO & Founder, WITS) · Actualizada: 2026-10-25 · https://security.wits.mx/guias/pentest-vs-auditoria/

## ¿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](https://csrc.nist.gov/pubs/sp/800/115/final), 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](https://security.wits.mx/guias/iso-27001-auditoria/) 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](https://security.wits.mx/guias/auditoria-seguridad-informatica/) 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](https://www.pcisecuritystandards.org/document_library/) o en [este resumen de los requisitos](https://learn.microsoft.com/en-us/entra/standards/pci-requirement-11).

> **Un escaneo no es un pentest** Un escáner automático encuentra versiones vulnerables y puertos abiertos. Un pentest intenta explotarlos y encadenarlos. PCI DSS los trata como requisitos distintos, y NIST los coloca en familias de técnicas diferentes.

## ¿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](https://security.wits.mx/chequeo-php/) 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](https://owasp.org/www-project-top-ten/): inyección, autenticación, secretos, dependencias.
- Actualizar lo que aparece en [las alertas de la semana](https://security.wits.mx/alertas/).
- 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?

1. Clasificar cada hallazgo por riesgo para tu operación, no solo por la calificación del informe.
2. Asignar responsable y fecha a cada corrección.
3. Corregir con registro del cambio y forma de revertirlo, para no romper producción.
4. Volver a probar. PCI DSS, en el requisito 11.4.4, pide repetir la prueba para verificar las correcciones.
5. Guardar la evidencia: qué se encontró, qué se cambió y la prueba de que quedó cerrado.
6. 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](https://owasp.org/www-project-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ó.

> **WITS no es una empresa de pentest** No hacemos pentest; protegemos. Preparamos tus sistemas antes de la prueba para que el informe no se llene de lo básico, y corregimos lo que el pentest encuentre, con evidencia antes y después de cada cierre. Para la prueba te recomendamos una firma especializada e independiente: quien corrige no debería ser quien prueba. PCI DSS también pide independencia organizacional de quien hace la prueba.

Así trabaja Security OS, la plataforma de [WITS](https://security.wits.mx/): 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](https://security.wits.mx/guias/ciberseguridad-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 pentest](https://security.wits.mx/guias/pentest-vs-auditoria/#contacto)

## Preguntas 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](https://csrc.nist.gov/pubs/sp/800/115/final)
- [PCI Security Standards Council: PCI DSS v4 (requisitos 11.3 y 11.4)](https://www.pcisecuritystandards.org/document_library/)
- [Microsoft Learn: texto de los requisitos 11.3 y 11.4 de PCI DSS v4](https://learn.microsoft.com/en-us/entra/standards/pci-requirement-11)
- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)