Contenido del artículo
Un pentest se hace al menos una vez al año y cada vez que hay un cambio importante: lanzamiento de un producto nuevo, una versión grande, una integración nueva, una migración a la nube, la compra de otra empresa, y también después de un incidente. Entre pentests los sistemas se escanean con regularidad, y después de las correcciones se hace un retest.
Abajo tienes una tabla de eventos que piden una prueba nueva, qué revisar y con qué profundidad, qué dicen de verdad PCI DSS, DORA y NIST, y cómo armar un plan de pruebas para un año.
En resumen
- El ritmo base es un pentest al año por cada sistema importante. Así lo describen PCI DSS para el entorno de pagos y NIST para la red de una organización. [1] [4]
- El calendario anual no elimina las pruebas tras cambios. Un módulo de pagos nuevo, una API nueva o una migración a la nube se prueban antes del lanzamiento o justo después.
- Entre pentests funciona el escaneo de vulnerabilidades, por ejemplo cada trimestre y tras cambios. Encuentra problemas conocidos, pero no ve errores de lógica.
- Después de corregir hace falta un retest. PCI DSS exige repetir la prueba para confirmar las correcciones. [1]
- Las entidades financieras en la UE prueban cada año los sistemas de funciones críticas según DORA, y las que designa el supervisor hacen TLPT cada tres años. [3]
Por qué no basta con el calendario: un pentest muestra un solo momento
Cualquier evaluación de seguridad es una foto del sistema en el momento de la prueba. NIST lo dice así y añade que por eso las organizaciones pueden exigir evaluaciones más frecuentes. [4] Un mes después del informe el equipo publica funciones nuevas, abre una API a un socio, cambia permisos. El informe sigue igual, el sistema ya no.
Por eso la frecuencia depende de dos cosas: el calendario y los cambios. A una empresa con pocas versiones e infraestructura estable a menudo le basta un pentest al año. Un SaaS que cambia cada semana y suma integraciones prueba los cambios grandes por separado, sin esperar a la prueba anual.
Cuándo hace falta un pentest nuevo: tabla de eventos
| Evento | Qué revisar | Con qué profundidad |
|---|---|---|
| Han pasado 12 meses desde la última prueba | Todo el alcance: perímetro externo, aplicaciones clave, red interna | Pentest completo |
| Lanzamiento de un producto o aplicación nueva | La aplicación nueva, su API, el inicio de sesión y los roles | Pentest completo antes del lanzamiento o justo después |
| Versión grande: roles nuevos, pagos, subida de archivos, cambios en el inicio de sesión | Las funciones cambiadas y todo lo conectado a ellas | Pentest dirigido a los cambios |
| Integración nueva o API para socios | Claves, permisos del socio, qué datos ve y qué puede cambiar | Pentest dirigido a la API |
| Migración a la nube o infraestructura nueva en la nube | Configuración de la nube, accesos, qué queda expuesto a internet | Revisión de configuración de la nube más pentest de aplicaciones |
| Compra o fusión con otra empresa | Red y cuentas de la empresa adquirida, conexiones entre redes | Evaluación de seguridad, después pentest de los puntos de conexión |
| Cambio en la segmentación de red | Si los segmentos están aislados entre sí | Prueba de segmentación |
| Incidente | Cómo entró el atacante, si ese camino está cerrado, si hay otros parecidos | Pentest dirigido después de la investigación |
| Hallazgos del último pentest corregidos | Los mismos hallazgos | Retest |
Qué cuenta como cambio importante lo decide cada empresa. El PCI Security Standards Council explica en su guía de pentest que depende de la evaluación de riesgos y de la configuración del entorno, y que un cambio que pueda afectar a la seguridad de la red o al acceso a datos de tarjetas puede considerarse importante. [5] Una regla sencilla para cualquier sector: si el cambio toca el inicio de sesión, los permisos, el dinero o los datos personales, es importante.
Para la nube explico qué se revisa en el artículo pentest de nube en AWS, Azure y GCP. Para una empresa adquirida conviene empezar con una evaluación de seguridad: da la visión general antes de la prueba en profundidad.
Qué dicen de verdad las normas y los reguladores
PCI DSS (la norma de seguridad de datos de tarjetas de pago). El pentest lo cubre el requisito 11.4. Los pentests interno (11.4.2) y externo (11.4.3) se hacen al menos una vez cada 12 meses y después de cualquier actualización o cambio importante de infraestructura o aplicación. Las vulnerabilidades explotables se corrigen y la prueba se repite para confirmar las correcciones (11.4.4). [1] Si la segmentación aísla el entorno de datos de tarjetas, se prueba cada 12 meses y tras cambios (11.4.5), y los proveedores de servicios cada seis meses (11.4.6). [1] [2] Los escaneos de vulnerabilidades se exigen al menos una vez cada tres meses (11.3.1 y 11.3.2). [1] La versión vigente, 4.0.1, se publicó en junio de 2024 y no añadió requisitos nuevos respecto a la 4.0. [6]
DORA (Reglamento UE 2022/2554 sobre resiliencia operativa digital del sector financiero, aplicable desde el 17 de enero de 2025). Las entidades financieras, salvo las microempresas, prueban al menos una vez al año todos los sistemas y aplicaciones TIC que soportan funciones críticas o importantes (artículo 24, apartado 6). El pentest aparece de forma explícita entre esas pruebas (artículo 25, apartado 1). Las entidades que identifica la autoridad competente hacen TLPT, pruebas de penetración guiadas por amenazas sobre sistemas en producción, al menos cada tres años (artículo 26). La autoridad puede reducir o aumentar esa frecuencia. [3] En qué se diferencia una prueba así de un pentest normal lo explico en Red Team o pentest.
NIST SP 800-115 (la guía técnica de NIST sobre pruebas de seguridad). Por su coste y su posible impacto en sistemas en producción, un pentest de la red una vez al año puede ser suficiente. Entre pentests NIST recomienda escaneos de red y de vulnerabilidades programados con regularidad. La frecuencia suele depender de los requisitos que la organización debe cumplir, y los recursos van primero a los sistemas de mayor prioridad. [4]
ISO 27001 y SOC 2. Si preparas una certificación ISO 27001 o un informe SOC 2, escribe la frecuencia del pentest y la lista de cambios importantes en tu propia política de seguridad y acuérdala con el auditor. Cómo se relacionan estos marcos con el pentest lo cuento en pentest para una startup SaaS.
Un plan de un año para una empresa con producto propio
Un pentest y un escaneo hacen trabajos distintos, así que el plan incluye los dos:
- De forma continua o cada trimestre: escaneo automático del perímetro externo y de las aplicaciones, y también tras cambios grandes de infraestructura. Esta parte la cubre una evaluación de vulnerabilidades.
- Una vez al año: un pentest completo de los sistemas clave. Es cómodo ligarlo al ciclo de presupuesto o a la renovación de contratos con clientes grandes.
- Antes de un lanzamiento grande: un pentest dirigido a las funciones nuevas, cuando todavía hay tiempo para corregir.
- Después de las correcciones: un retest de los hallazgos críticos y altos.
- Una vez al año y tras cambios en la red: una prueba de segmentación, si tu protección depende de separar la red.
En qué se diferencia un escaneo de una prueba manual, y por qué uno no sustituye al otro, se explica en pentest o escaneo de vulnerabilidades. Cómo cerrar hallazgos y pasar la segunda comprobación, en qué hacer después de un pentest.
Errores habituales
- Un pentest al año y ninguno tras los cambios. Una versión grande un mes después del informe queda sin probar hasta el año siguiente.
- El mismo alcance cada año. El año pasado se probó la web, y este año también hay una app móvil y una API. El alcance se revisa antes de cada prueba.
- Un escaneo en lugar de un pentest. Un escáner no detecta que un cliente ve pedidos ajenos si cambia un número en la petición.
- Sin retest. Sin una segunda comprobación no sabes si la corrección funcionó.
- Esperar a la prueba anual después de un incidente. El camino que usó el atacante se prueba justo después de la investigación.
- Probar en mitad de una gran migración. NIST menciona que a veces la prueba se aplaza hasta terminar una actualización grande. [4] Si no, el informe describe un sistema que en una semana ya no existirá.
Lista: plan anual de pentests
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Basta con un pentest al año?
Para un sistema estable que cambia poco, sí. Si lanzas funciones o integraciones a menudo, o cambias la infraestructura, prueba los cambios grandes por separado en lugar de esperar a la prueba anual.
¿Un escaneo de vulnerabilidades puede sustituir a un pentest?
No. Un escáner encuentra vulnerabilidades conocidas, y un pentest comprueba qué puede hacer un atacante con el sistema, también a través de errores de lógica. PCI DSS exige los dos: escaneos cada trimestre, pentest cada año y tras cambios. [1]
¿Cada cuánto exige PCI DSS un pentest?
Pentest interno y externo al menos una vez cada 12 meses y tras cambios importantes. Pruebas de segmentación cada 12 meses, o cada seis meses para proveedores de servicios. [1] [2]
¿Qué exige DORA sobre el pentest?
Las entidades financieras prueban cada año los sistemas que soportan funciones críticas o importantes, y el pentest está en la lista de pruebas. Las entidades que designa el supervisor hacen TLPT cada tres años. [3]
¿Hace falta un pentest después de cada versión?
No. Para las versiones habituales bastan las comprobaciones automáticas. Un pentest aparte hace falta cuando la versión cambia el inicio de sesión, los permisos, los pagos, el manejo de datos personales o abre APIs nuevas.
Referencias
- Microsoft Learn: PCI DSS Requirement 11 (requirement text for 11.3 and 11.4) learn.microsoft.com
- PCI SSC FAQ 1447: How often must service providers test segmentation controls? pcisecuritystandards.org
- EUR-Lex: Regulation (EU) 2022/2554 (DORA) eur-lex.europa.eu
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
- PCI SSC: Penetration Testing Guidance v1.1 listings.pcisecuritystandards.org
- PCI SSC: Just Published: PCI DSS v4.0.1 blog.pcisecuritystandards.org
