Gestión de vulnerabilidades en PCI DSS 4.0.1: aprobar el escaneo trimestral ya no basta

Durante años, muchos equipos trataron la gestión de vulnerabilidades de PCI DSS como una fecha en el calendario: hacer los escaneos trimestrales, conseguir el informe aprobado del proveedor de escaneo autorizado (ASV) y archivarlo para el auditor. PCI DSS v4.x mantiene los escaneos trimestrales, pero ya no les deja cargar con todo el programa. Desde el 31 de marzo de 2025 son obligatorios los requisitos que en la v4.0 tenían fecha futura, y varios cambian cómo se encuentran, se priorizan y se cierran las vulnerabilidades.

Esta guía recorre los requisitos de vulnerabilidades de PCI DSS v4.0.1, qué cambió y qué evidencia te va a pedir el evaluador.

Dónde estamos

El PCI Security Standards Council retiró PCI DSS v3.2.1 el 31 de marzo de 2024. Publicó la v4.0.1, una revisión limitada, en junio de 2024. De los 64 requisitos nuevos de la v4.0, 51 tenían fecha futura y entraron en vigor el 31 de marzo de 2025. Es decir, la transición terminó: hoy una evaluación se hace contra la v4.x completa.

Paso 1: asigna un nivel de riesgo a cada vulnerabilidad (requisito 6.3.1)

Todo lo demás depende del requisito 6.3.1. Tienes que identificar las vulnerabilidades nuevas a partir de fuentes del sector y asignar a cada una un nivel de riesgo que identifique, como mínimo, las que se consideran de riesgo alto o críticas para tu entorno.

Hay dos consecuencias que se pasan por alto con facilidad:

• La clasificación es tuya. El CVSS del fabricante es un dato de entrada, no la respuesta. La evidencia de explotación, la exposición y el papel del sistema en el entorno de datos de tarjetas son factores legítimos, siempre que el método esté documentado.
• Tu clasificación manda en los demás requisitos. Los requisitos 11.3.1 y 11.3.1.3 dicen que las vulnerabilidades de riesgo alto y críticas se resuelven según los niveles de riesgo que la entidad definió en el requisito 6.3.1.

Si tu clasificación es solo la columna de severidad del escáner, estás desaprovechando la parte más útil de la norma. Explicamos un método práctico en cómo priorizar vulnerabilidades.

Paso 2: parchea las críticas en un mes (requisito 6.3.3)

El requisito 6.3.3 exige instalar los parches o actualizaciones de las vulnerabilidades críticas dentro del mes siguiente a su publicación. El resto de los parches de seguridad aplicables se instala en un plazo adecuado según tu propia evaluación del riesgo.

Aquí la v4.0.1 cambió el texto. En la v4.0, el plazo de un mes cubría las vulnerabilidades críticas y las de riesgo alto. La v4.0.1 volvió a la redacción de la v3.2.1, así que el plazo fijo de un mes aplica solo a las críticas. Las de riesgo alto no quedan libres: se tienen que resolver según el 11.3.1, en un plazo que tú defines y puedes justificar.

Un SLA de un mes solo sirve si lo puedes medir. Mide el tiempo de corrección por severidad, no como un único promedio; lo vemos en SLA de corrección y MTTR.

Paso 3: escaneos internos, ahora autenticados (requisitos 11.3.1 y 11.3.1.2)

El requisito 11.3.1 mantiene las reglas conocidas de los escaneos internos:

• Como mínimo una vez cada tres meses.
• Las vulnerabilidades de riesgo alto y críticas, según tu clasificación del 6.3.1, se resuelven.
• Se hacen reescaneos que confirman que se resolvieron.
• La herramienta se mantiene actualizada y los escaneos los hace personal calificado e independiente dentro de la organización.

El cambio grande es el requisito 11.3.1.2, uno de los que tenían fecha futura: los escaneos internos tienen que ser autenticados. Eso significa:

• Los sistemas que no aceptan credenciales para el escaneo quedan documentados.
• Los que sí las aceptan se escanean con privilegios suficientes.
• Si las cuentas de escaneo permiten iniciar sesión de forma interactiva, se gestionan según el requisito 8.2.2.

Un escaneo autenticado ve los paquetes instalados, los parches que faltan y la configuración local que un escaneo sin credenciales solo puede adivinar. La primera vez que lo actives, espera que el número de hallazgos suba, a veces mucho. No es un retroceso: es visibilidad que no tenías. Comparamos los enfoques en escaneo con agente o sin agente.

Paso 4: el resto de los hallazgos también necesita un plan (requisito 11.3.1.1)

Con la v3.2.1, muchos equipos ignoraban en silencio todo lo que estaba por debajo de "alto". El requisito 11.3.1.1 cierra ese hueco. Todas las demás vulnerabilidades aplicables, las que no son de riesgo alto ni críticas, se tienen que tratar según el riesgo definido en un análisis de riesgo específico (TRA, por sus siglas en inglés) hecho conforme al requisito 12.3.1, con reescaneos cuando haga falta.

En la práctica, el TRA es donde dejas por escrito en cuánto tiempo se corrigen los hallazgos medios y bajos, y por qué eso es aceptable en tu entorno. Tiene que estar documentado y revisarse periódicamente. Cuando decides no corregir algo, trátalo como una decisión formal con responsable y fecha de vencimiento, como explicamos en aceptación del riesgo de vulnerabilidades.

Paso 5: escaneos externos y cambios significativos (requisitos 11.3.2, 11.3.1.3 y 11.3.2.1)

El requisito 11.3.2 sigue exigiendo escaneos externos al menos una vez cada tres meses, hechos por un ASV aprobado por el PCI SSC, con las vulnerabilidades resueltas y reescaneos hasta que el escaneo cumpla los requisitos de aprobación de la guía del programa ASV.

También hay que escanear después de cualquier cambio significativo:

• Internos (11.3.1.3): se resuelven las vulnerabilidades de riesgo alto y críticas según tu clasificación del 6.3.1, con reescaneos cuando haga falta.
• Externos (11.3.2.1): se resuelven las vulnerabilidades con CVSS de 4.0 o más, con reescaneos cuando haga falta.

Estos escaneos posteriores a un cambio no tienen que hacerlos un QSA ni un ASV, pero sí personal calificado e independiente.

Qué te va a pedir el evaluador

Un informe trimestral ya no basta por sí solo. Prepárate para mostrar:

1. Tu método de clasificación de riesgo documentado (6.3.1) y ejemplos de su aplicación.
2. Evidencia de que los parches críticos se instalaron en menos de un mes (6.3.3).
3. Cuatro trimestres de escaneos internos autenticados, más la lista de sistemas que no aceptan credenciales (11.3.1, 11.3.1.2).
4. Reescaneos que muestran que se cerraron los hallazgos de riesgo alto y críticos.
5. El TRA que fija los plazos del resto de los hallazgos (11.3.1.1, 12.3.1).
6. Cuatro escaneos trimestrales del ASV aprobados (11.3.2).
7. Escaneos después de cada cambio significativo (11.3.1.3, 11.3.2.1).

Preguntas frecuentes

¿Aprobar el escaneo del ASV significa cumplir los requisitos de vulnerabilidades? No. Cubre el 11.3.2. Los escaneos internos autenticados, la clasificación de riesgo, los plazos de parcheo y el TRA son requisitos aparte.

¿Podemos clasificar como alta o media una vulnerabilidad que el fabricante marca como crítica? La norma pide tu propia clasificación de riesgo, así que sí, si el método está documentado y se aplica de forma coherente. El evaluador va a querer ver el razonamiento, no solo un número más bajo.

¿Los plazos de PCI DSS reemplazan nuestros SLA internos? Fijan un mínimo para el entorno de datos de tarjetas. Muchos equipos aplican los mismos SLA en todas partes para tener un solo proceso, no dos.

Cómo ayuda priorIQ.ai

priorIQ.ai no es un ASV y no reemplaza tus escaneos externos trimestrales. Ayuda con el trabajo que los rodea. PriorIQ Core concilia los hallazgos de ScannerIQ o de los escáneres que ya usas, como Tenable, Qualys, Rapid7 o Microsoft Defender, y los prioriza con CVSS, EPSS, CISA KEV, señales de exploit y contexto de negocio, lo que te da una base documentada para tu clasificación del 6.3.1. El backlog de mitigación sigue cada elemento con responsable, estado del ticket y SLA, las excepciones de riesgo quedan auditadas y el registro de auditoría inmutable guarda cada decisión de corrección. CodeIQ añade informes de PCI DSS para los hallazgos de código. Solicita una demo.