¿Con qué frecuencia se debe realizar una prueba de penetración?
Respuesta corta: al menos una vez cada 12 meses, y de nuevo tras cualquier cambio significativo en los sistemas dentro del alcance. Esa regla de dos partes, calendario más cambio, es el mínimo práctico en todos los marcos de trabajo con los que se encuentra un comprador. Solo PCI DSS lo establece como un requisito estricto. SOC 2 e ISO 27001 no mencionan ninguna frecuencia; se basan en el riesgo, y la frecuencia anual se ha convertido simplemente en lo que esperan los auditores. Si tu entorno despliega código cada semana o gestiona datos de alto valor, una vez al año es un mínimo que superar, no un objetivo a alcanzar.
La pregunta surge porque «anual» suena como una regla impuesta desde alguna instancia oficial. Para un estándar lo es. Para los demás, es una convención que surgió en torno a un lenguaje basado en riesgos, y saber cuál es cuál evita que compres en exceso o te quedes corto en una auditoría. Esto es lo que dice realmente cada uno.
La versión corta, por marco de trabajo
Cuatro motivos llevan a la mayoría de los compradores a solicitar una prueba: un procesador de tarjetas, un informe SOC 2, un certificado ISO o un formulario de seguro. Solo uno de ellos prescribe una cifra.
| Factor impulsor | ¿Especifica una frecuencia? | Frecuencia que adoptan los compradores |
|---|---|---|
| PCI DSS v4.0 | Sí, prescriptiva | Al menos cada 12 meses y tras un cambio significativo |
| SOC 2 (AICPA) | No, basada en riesgos | Anual, dentro de la ventana de Tipo 2, por convención de los auditores |
| ISO/IEC 27001 | No, basada en riesgos | Anual es lo común; la frecuencia la define tu evaluación de riesgos |
| Ciberseguro | Varía según la aseguradora | A menudo una declaración anual; consulta la póliza específica |
| Sin mandato alguno | N/A | Mínimo anual, más frecuente si cambias rápido o manejas datos de alto valor |
La regla de dos partes: calendario más cambio
Cada respuesta creíble sobre la frecuencia consiste en realidad en dos reglas superpuestas, y omitir cualquiera de ellas deja una brecha.
La parte del calendario existe porque una prueba de penetración es un ejercicio en un momento puntual. Describe los sistemas dentro del alcance, durante la ventana de evaluación, frente a las técnicas en las reglas de participación. Se descubren nuevas clases de vulnerabilidades, se publican nuevos exploits y tu equipo sigue desplegando código. Una prueba anual reinicia ese reloj antes de que la imagen quede demasiado desfasada.
La parte del cambio existe porque el calendario no sabe cuándo rediseñaste tu flujo de autenticación o expusiste una nueva API. Una prueba de marzo no te dice nada sobre el servicio que lanzaste en junio. Por eso todos los marcos serios combinan «al menos cada 12 meses» con «y tras cualquier cambio significativo», y es la parte que los compradores omiten con mayor frecuencia.
Qué se considera un cambio significativo
PCI DSS deja la definición de «significativo» a criterio de cada organización, que debe defenderla, pero los ejemplos del sector son consistentes. Considera cualquiera de los siguientes como un detonante para evaluar el alcance afectado, independientemente de cuándo se realizó la última prueba anual:
- Una actualización mayor de la aplicación o la reescritura de un componente relevante para la seguridad.
- Un nuevo servicio expuesto a internet, un subdominio o una API que amplíe lo que un atacante puede alcanzar.
- Una migración a la nube, o un cambio sustancial en la arquitectura en la nube o IAM.
- Un cambio en la autenticación, en el inicio de sesión único (SSO) o en la gestión de sesiones.
- Un cambio en la segmentación de red, reglas de firewall o en cómo se aíslan los entornos.
- Una adquisición o una nueva integración con terceros que incorpore la superficie de exposición de otra entidad a la tuya.
El hilo conductor es la exposición. Si el cambio altera lo que es accesible desde el exterior, cómo se demuestra la identidad o dónde se ubica un límite de confianza, la última prueba ya no refleja la realidad.
Lo que dice realmente cada marco de cumplimiento
PCI DSS v4.0 es el prescriptivo. El Requisito 11.4 exige pruebas de penetración internas y externas al menos una vez cada 12 meses y tras cualquier actualización o cambio significativo en la infraestructura o en las aplicaciones, siguiendo una metodología documentada basada en un enfoque aceptado por la industria, como NIST SP 800-115. Cuando se utiliza la segmentación para mantener los sistemas fuera del entorno de datos de tarjetahabientes, esa segmentación se evalúa al menos cada 12 meses para comerciantes y al menos cada 6 meses para proveedores de servicios, y los hallazgos se vuelven a evaluar tras su remediación. Este es el «con qué frecuencia» más claro que ofrece cualquiera de los marcos de trabajo.
SOC 2 no especifica ninguna frecuencia. Los Criterios de Servicios de Confianza de AICPA están redactados como objetivos, no como calendarios, por lo que no hay ninguna línea que exija una prueba anual. En la práctica, los auditores esperan una al menos anualmente, programada para que caiga dentro del periodo de observación de Tipo 2. Escribimos los detalles sobre qué criterios apuntan a las pruebas en ¿requiere SOC 2 una prueba de penetración?
ISO/IEC 27001 se basa explícitamente en el riesgo. Exige que se gestionen las vulnerabilidades técnicas y se verifiquen los controles, y vincula la frecuencia a tu propia evaluación de riesgos y plan de tratamiento, en lugar de a un calendario fijo. Las organizaciones certificadas coinciden en considerar las pruebas anuales como la base justificable, probando con mayor frecuencia los activos de mayor riesgo. La cifra la debes justificar tú, no es una constante que se te entregue.
El ciberseguro depende de la aseguradora. Algunas pólizas preguntan si realizas pruebas de manera periódica y consideran «anualmente» como la respuesta esperada; otras ni siquiera lo preguntan. Lo más honesto es leer la solicitud específica en lugar de asumir, que es el tema de ¿necesito un pentest para el ciberseguro?
Cuando una vez al año no es suficiente
Una prueba anual es un mínimo, y algunos entornos lo superan rápidamente. Evalúa con mayor frecuencia cuando:
- Despliegas código continuamente. Si producción cambia semanalmente, una prueba anual estará desfasada durante once meses al año. Los equipos en esta situación pasan a realizar pruebas por cada despliegue en las rutas críticas, o a un modelo de evaluación continua, manteniendo la prueba anual completa como pilar.
- Almacenas datos de alto valor. Pagos, registros médicos y grandes volúmenes de datos personales aumentan el coste de equivocarse, lo que justifica pruebas más frecuentes en los sistemas que interactúan con ellos.
- Acabas de tener un incidente o susto. Tras un incidente, un intento fallido o una vulnerabilidad crítica en un componente del que dependes, volver a evaluar el área afectada es más económico que asumir que el parche fue impecable.
Nada de esto reemplaza la prueba anual. Se añade por encima, porque un servicio completo y acotado realizado por profesionales sénior tiene un nivel de profundidad distinto al de una reevaluación puntual de un cambio.
El error: tratar la fecha como el entregable
La forma más común de equivocarse con la frecuencia es tratar el pentest como un certificado con fecha de caducidad, ejecutarlo el último día válido y no modificar nada de lo aprendido. Una prueba encargada solo para cumplir el trámite suele delimitarse de forma tan estrecha que se supera fácilmente y con la suficiente superficialidad como para no detectar cómo entraría realmente un atacante. La fecha del informe satisface al auditor; no dificulta que te vulneren.
Entre las pruebas programadas, tu exposición sigue cambiando, la mires o no: un subdominio olvidado, un servicio que nunca debió ser público, una credencial filtrada. Conocer tu superficie de ataque externa de forma continua es el complemento económico para la evaluación periódica en profundidad, y no es la misma compra que un pentest. Si todavía estás intentando determinar qué servicio necesitas en primer lugar, ¿revisión, escaneo o pentest completo? define las diferencias.
¿Con qué frecuencia se debe realizar una prueba de penetración? Respuestas rápidas
¿Con qué frecuencia se debe realizar una prueba de penetración?
Al menos una vez cada 12 meses, y de nuevo tras cualquier cambio significativo en los sistemas dentro del alcance. Esa regla de dos partes es el mínimo práctico en todos los estándares que les importan a los compradores. Los entornos de rápido desarrollo o con datos de alto valor deberían realizar pruebas con mayor frecuencia, incluso por cada despliegue o de forma continua.
¿Exige PCI DSS una prueba de penetración anual?
Sí. El requisito 11.4 de PCI DSS v4.0 exige pruebas de penetración internas y externas al menos una vez cada 12 meses y tras cualquier cambio significativo en la infraestructura o en las aplicaciones. Cuando la segmentación aísla el entorno de datos de tarjetahabientes, esa segmentación se evalúa al menos cada 12 meses para comerciantes y al menos cada 6 meses para proveedores de servicios.
¿Con qué frecuencia exigen un pentest SOC 2 e ISO 27001?
Ninguno especifica una frecuencia fija. Ambos se basan en el riesgo: SOC 2 deja la evidencia a criterio de tu auditor, e ISO 27001 vincula las pruebas a tu evaluación de riesgos. En la práctica, la frecuencia anual se ha convertido en la cadencia aceptada que esperan los auditores, programada para coincidir con el periodo de observación de SOC 2 Tipo 2.
¿Cuándo deberías realizar pruebas fuera del ciclo anual?
Tras cualquier cambio significativo: una actualización mayor, un nuevo servicio o subdominio expuesto a internet, una migración a la nube, un cambio en la autenticación o SSO, un cambio en la red o segmentación, o una adquisición. La última prueba solo describía el entorno tal y como estaba ese día.
Fuentes
- PCI Security Standards Council, Requisito 11.4 de PCI DSS v4.0 (metodología de pruebas de penetración, frecuencia y pruebas de segmentación).
- Criterios de Servicios de Confianza de AICPA (SOC 2), redactados como objetivos basados en riesgos sin una frecuencia de prueba fija.
- ISO/IEC 27001, gestión de vulnerabilidades técnicas y verificación de controles basadas en riesgos.
- NIST SP 800-115, Guía Técnica para Pruebas y Evaluaciones de Seguridad de la Información, citada como metodología aceptada.
Lecturas relacionadas
- ¿Requiere SOC 2 una prueba de penetración?
- ¿Necesito un pentest para el ciberseguro?
- ¿Cuánto cuesta una prueba de penetración?
No permitas que la fecha anual sea la única revisión.
Nuestra revisión de $100 muestra lo que ve un atacante desde el exterior a día de hoy, con un operador sénior explicando los resultados. Es el complemento económico a un pentest periódico, no un sustituto, y te indicaremos cuál es el que necesitas.
Reserva una revisión por $100