Periodicidad
Actividades recurrentes por marco temporal
Actividades Recurrentes por Marco Temporal — Vista “Cuándo”
Vista “cuándo” de los controles recurrentes de PCI DSS v4.0.1, agrupados por marco temporal.
Complemento de periodicity-bau-significant-change.md (vista “qué/cómo”). No duplica el detalle de ese archivo; cada tabla referencia al otro.
Cómo leer este archivo
- Bloque 1: frecuencias fijas establecidas por el estándar.
- Bloque 2: frecuencias que la entidad define mediante análisis de riesgo específicos (TRA — Req 12.3.1). El estándar dice “periódicamente”.
- Bloque 3: actividades orientado por evento — no tienen un calendario fijo, sino un disparador.
Si un requisito aparece en más de un bloque, se indica con nota cruzada.
Alta prioridad para examen: el ISA pregunta intensivamente por marcos temporales exactos. Los distractores juegan con la diferencia entre “every 90 days” y “every three months” (equivalentes), “every 12 months” y “annually” (equivalentes), o entre frecuencias fijas y TRA. Ver definiciones en (PCI DSS v4.0.1, p. 25 LA).
Bloque 1 — Frecuencias fijas por el estándar
Orden: inmediato → dentro de 24 h → diario → semanal → 90 días → trimestral → semestral → anual → mayor.
Inmediatamente / Con prontitud
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Inmediatamente | 8.2.5 — Acceso logico de usuarios terminados revocado inmediatamente. El examen distingue entre cuentas desactivadas (inmediato) y cuentas inactivas (90 dias — Req 8.2.6). | NO | PCI DSS v4.0.1, Req 8.2.5, p. 181 LA |
| Inmediatamente | 8.3.5 — Contrasenas/passphrases de acceso cambiadas inmediatamente en el primer uso tras ser asignadas o reseteadas. | NO | PCI DSS v4.0.1, Req 8.3.5, p. 193 LA |
| Inmediatamente | 9.3.1.1 — Acceso fisico a areas sensibles revocado inmediatamente al terminar la relacion del individuo (devolucion/deshabilitacion de tarjetas, llaves, etc.). | NO | PCI DSS v4.0.1, Req 9.3.1.1, p. 217 LA |
| Con prontitud al detectarse | 10.7.2 — Fallas de sistemas de control de seguridad criticos detectadas, alertadas y tratadas prontamente (NSC, IDS/IPS, detección de cambios, anti-malware, audit log, controles de segmentación). Activo a partir del 31 de marzo de 2025 para todos. | NO | PCI DSS v4.0.1, Req 10.7.2, p. 256 LA |
| Con prontitud al detectarse | 10.7.3 — Respuesta a fallas de cualquier sistema de control de seguridad critico: restaurar funcion, documentar duracion, causa y remediacion, identificar implicaciones de seguridad. | NO | PCI DSS v4.0.1, Req 10.7.3, p. 257 LA |
| Investigado inmediatamente | 6.4.1 (opcion WAF/automatizado) — Si la entidad elige solucion automatizada para aplicaciones web publicas, las alertas del WAF/AST deben investigarse inmediatamente. Nota: si la entidad elige evaluacion manual, la frecuencia es anual + cambio significativo (ver sección anual). | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 LA |
Diario
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Al menos una vez al día | 10.4.1 — Revision de los siguientes audit logs: (a) eventos de seguridad, (b) logs de sistemas que almacenan, procesan o transmiten CHD/SAD, (c) logs de componentes criticos de sistema, (d) logs de servidores y sistemas de control de acceso criticos, (e) logs de sistemas de criptografia criticos. “Diario” = todos los dias del año, no solo dias habiles. Alta prioridad: la falta de revision diaria es hallazgo critico en una evaluación. Ver 10.4.2 para logs de otros componentes (frecuencia por TRA). | NO | PCI DSS v4.0.1, Req 10.4.1, p. 246 LA |
Al menos semanalmente
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Al menos semanalmente | 11.6.1 — Mecanismo de deteccion de cambios y manipulacion en HTTP headers y scripts de paginas de pago como las recibe el browser del consumidor. La entidad puede elegir: (A) al menos semanal, o (B) a la frecuencia definida en su TRA (ver Bloque 2). Alta prioridad: este mecanismo es distinto al detección de cambios de FIM (10.x); aqui se monitorea el contenido de la pagina en el browser. Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 11.6.1, p. 287 LA |
Dentro de 90 días de inactividad
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Dentro de 90 días de inactividad | 8.2.6 — Cuentas de usuario inactivas removidas o deshabilitadas. Disparador: inactividad de la cuenta (no un ciclo de calendario). Las cuentas inactivas son vectores de ataque porque los cambios pasan desapercibidos. | NO | PCI DSS v4.0.1, Req 8.2.6, p. 182 LA |
| Al menos una vez cada 90 días | 8.3.9 — Cambio de contrasena/passphrase al menos cada 90 dias, SOLO cuando la contrasena es el unico factor de autenticacion. Si hay MFA, este requisito cambia. La alternativa es analisis dinamico de la postura de seguridad en tiempo real. Alta prioridad: “every 90 days” = “every three months” = trimestral. | NO | PCI DSS v4.0.1, Req 8.3.9, p. 192 LA |
Al menos una vez cada tres meses (“trimestral”)
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| al menos una vez cada tres meses (“trimestral”) | 3.2.1 — Proceso para verificar que los datos de cuenta almacenados que superan el periodo de retencion definido han sido eliminados o inutilizados de forma segura. El proceso debe ejecutarse al menos trimestralmente. Alta prioridad: la entidad no solo debe tener politica de retencion; debe tener evidencia de que el proceso de verificacion y eliminacion se ejecuto. | NO | PCI DSS v4.0.1, Req 3.2.1, p. 76 LA |
| al menos una vez cada tres meses (“trimestral”) | 11.2.1 — Todos los puntos de acceso inalambrico son detectados e identificados, incluyendo los no autorizados. El proceso puede ser automatizado (monitoreo continuo = cumple el requisito) o manual (testing al menos trimestral). | NO | PCI DSS v4.0.1, Req 11.2.1, p. 262 LA |
| al menos una vez cada tres meses (“trimestral”) | 11.3.1 — Escaneos de vulnerabilidades internas. Las vulnerabilidades de alta/critica deben corregirse; las de menor riesgo se tratan por TRA (ver 11.3.1.1 en Bloque 2). No requiere ASV. Ver 11.3.1.2 (abajo) para el requisito de escaneo autenticado. | NO | PCI DSS v4.0.1, Req 11.3.1, p. 265 LA |
| al menos una vez cada tres meses (“trimestral”) | 11.3.1.2 — Escaneos internos de vulnerabilidades mediante escaneo autenticado (authenticated scanning). Es el metodo obligatorio para realizar los escaneos internos de 11.3.1. Activo a partir del 31 de marzo de 2025. Los escaneos autenticados detectan mas vulnerabilidades que los escaneos sin credenciales. | NO | PCI DSS v4.0.1, Req 11.3.1.2, p. 268 LA |
| al menos una vez cada tres meses (“trimestral”) | 11.3.2 — Escaneos de vulnerabilidades externas por un PCI SSC Approved Scanning Vendor (ASV). El resultado debe ser un “análisis aprobado”. Alta prioridad: la diferencia entre 11.3.1 (interno, sin ASV) y 11.3.2 (externo, ASV obligatorio) es una pregunta tipica. Ver tambien 11.3.2.1 (Bloque 3: post cambio significativo). | NO | PCI DSS v4.0.1, Req 11.3.2, p. 270 LA |
| al menos una vez cada tres meses (“trimestral”) | 12.4.2 — Revisiones de que el personal cumple las politicas y procedimientos operativos de seguridad. Las revisiones las realiza personal distinto al responsable de la tarea. Incluye: revision de logs, reglas de NSC, cambios de aplicacion, gestion de cuentas, controles de acceso fisico, TPSP/MSSP, respuesta a incidentes, etc. Solo aplica a proveedores de servicio. | SI | PCI DSS v4.0.1, Req 12.4.2, p. 301 LA |
Al menos una vez cada seis meses
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| al menos una vez cada seis meses | 1.2.7 — Revision de configuraciones de NSC al menos cada seis meses para confirmar que siguen siendo relevantes y efectivos. La revision da oportunidad de limpiar reglas obsoletas, incorrectas o innecesarias. Alta prioridad: 1.2.7 (revision de configuracion) es distinto de 12.4.2 (SP: confirmar que la revision ocurrio, trimestral). | NO | PCI DSS v4.0.1, Req 1.2.7, p. 48 LA |
| al menos una vez cada seis meses | 7.2.4 — Revision de todas las cuentas de usuario y privilegios de acceso relacionados, incluyendo cuentas de terceros/vendors. La revision confirma que el acceso es apropiado para la funcion. Ver 7.2.5.1 (Bloque 2) para cuentas de aplicacion/sistema (TRA). | NO | PCI DSS v4.0.1, Req 7.2.4, p. 167 LA |
| al menos una vez cada seis meses y tras cambios en controles o métodos de segmentación | 11.4.6 — Prueba de controles de segmentacion para proveedores de servicio que usan segmentacion. Frecuencia semestral vs. anual para entidades no SP (11.4.5). Solo aplica a proveedores de servicio. Ver Bloque 3 para el disparador de cambio en controles/metodos de segmentacion. | SI | PCI DSS v4.0.1, Req 11.4.6, p. 280 LA |
| al menos una vez cada seis meses y tras un cambio significativo | 12.5.2.1 — Confirmacion de la determinación del alcance PCI DSS para proveedores de servicio. Frecuencia semestral vs. anual para otros (12.5.2). Tambien se confirma tras cambio significativo. Solo aplica a proveedores de servicio. Ver Bloque 3 para el disparador de cambio significativo. | SI | PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA |
| al menos una vez cada seis meses mediante prueba de penetración | A1.1.4 — Confirmacion de la efectividad de controles de separacion logica entre entornos de clientes en SP multi-tenant mediante prueba de penetración. Adicional a los pruebas de penetración de 11.4.6. Solo aplica a multi-tenant proveedores de servicio (Apendice A1). | SI | PCI DSS v4.0.1, Req A1.1.4, p. 337 LA |
Al menos una vez cada 12 meses (“anualmente”)
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| al menos una vez cada 12 meses (“anualmente”) | 6.2.2 — Capacitacion en codificacion segura para personal de desarrollo de software a medida (software a medida y personalizado). Incluye: OWASP Top 10, tecnicas de codificacion segura, uso de componentes de seguridad. Alta prioridad: aplica al personal de desarrollo, no a todos los empleados. Ver 12.6.3 para la concientizacion general. | NO | PCI DSS v4.0.1, Req 6.2.2, p. 137 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras cambios significativos | 6.4.1 (opcion evaluacion manual) — Evaluacion de seguridad de aplicaciones web publicas por una entidad especializada en seguridad de aplicaciones, usando herramientas/metodos de evaluacion. Incluye testing de todos los ataques del Req 6.2.4. La entidad puede elegir esta opcion o la de solucion automatizada continua. Ver Bloque 3 para el disparador de cambio significativo. | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 LA |
| al menos una vez cada 12 meses (“anualmente”) | 9.4.1.2 — Revision de seguridad de la(s) ubicacion(es) de almacenamiento de backup de medios offline con CHD. La revision confirma que los controles de seguridad fisica siguen en vigor. | NO | PCI DSS v4.0.1, Req 9.4.1.2, p. 221 LA |
| al menos una vez cada 12 meses (“anualmente”) | 9.4.5.1 — Inventario de medios electronicos con CHD. El evaluador verifica logs del inventario. Alta prioridad: el inventario (anual) es distinto de la clasificacion de medios (Req 9.4.2, continua). | NO | PCI DSS v4.0.1, Req 9.4.5.1, p. 224 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras cualquier actualización o cambio significativo de infraestructura o aplicación | 11.4.2 — Prueba de penetracion interna: simula un ataque desde dentro de la red. Debe seguir la metodologia de 11.4.1 y realizarse por recurso calificado con independencia organizacional; no requiere QSA ni ASV. Ver Bloque 3 para el disparador de cambio significativo. | NO | PCI DSS v4.0.1, Req 11.4.2, p. 276 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras cualquier actualización o cambio significativo de infraestructura o aplicación | 11.4.3 — Prueba de penetracion externa: simula un ataque desde fuera de la red. Debe seguir la metodologia de 11.4.1 y realizarse por recurso calificado con independencia organizacional; no requiere QSA ni ASV. Ver Bloque 3 para el disparador de cambio significativo. | NO | PCI DSS v4.0.1, Req 11.4.3, p. 277 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras cambios en controles o métodos de segmentación | 11.4.5 — Prueba de controles de segmentacion para entidades que usan segmentacion. Solo aplica si la entidad usa segmentacion para aislar el CDE. Ver Bloque 3 para el disparador de cambio en controles/metodos de segmentacion. | NO | PCI DSS v4.0.1, Req 11.4.5, p. 279 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.1.1 — Revision de la politica general de seguridad de la informacion. La revision confirma que la politica es actual y refleja el entorno de riesgo. Actualizacion cuando sea necesario (no necesariamente anual). | NO | PCI DSS v4.0.1, Req 12.1.1, p. 290 LA |
| Revisión al menos una vez cada 12 meses (“anualmente”) | 12.3.1 — Revision de cada TRA al menos anualmente para determinar si los resultados siguen siendo validos. Meta-requisito: toda actividad “periódicamente” en PCI DSS requiere una TRA documentada conforme a 12.3.1. Alta prioridad: la ausencia de TRA es incumplimiento en si misma. | NO | PCI DSS v4.0.1, Req 12.3.1, p. 295 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.3.2 — TRA para cada control implementado mediante Enfoque Personalizado, revisada al menos anualmente. Solo aplica si la entidad usa el Enfoque Personalizado. | NO | PCI DSS v4.0.1, Req 12.3.2, p. 297 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.3.3 — Revision de cipher suites y protocolos criptograficos en uso. Confirma que los algoritmos siguen siendo seguros. Complementa pero no reemplaza el uso continuo de criptografia fuerte. | NO | PCI DSS v4.0.1, Req 12.3.3, p. 298 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.3.4 — Revision de tecnologias de hardware y software en uso para confirmar que siguen siendo soportadas y cumplen los requisitos de seguridad. Si una tecnologia ya no es soportada, debe haber un plan de remediacion. | NO | PCI DSS v4.0.1, Req 12.3.4, p. 299 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras un cambio significativo | 12.5.2 — Confirmacion y documentacion de la determinación del alcance PCI DSS para todos los tipos de entidad. Incluye revision de todos los componentes del sistema, flujos de datos de cuenta, y conexiones con terceros. Ver 12.5.2.1 para SP (semestral). Ver Bloque 3 para el disparador de cambio significativo. | NO | PCI DSS v4.0.1, Req 12.5.2, p. 304 LA |
| Revisado al menos una vez cada 12 meses (“anualmente”) | 12.6.2 — Revision del programa de concientizacion de seguridad para confirmar que el material esta actualizado respecto a amenazas actuales. Distinguir entre revisar el programa (este requisito) y dar la capacitacion (12.6.3). | NO | PCI DSS v4.0.1, Req 12.6.2, p. 309 LA |
| Al ingresar y al menos una vez cada 12 meses (“anualmente”) | 12.6.3 — Capacitacion en concientizacion de seguridad para todo el personal. Doble disparador: al ingresar (orientado por evento) y anualmente (calendario). El personal debe reconocer al menos anualmente haber leido y entendido la politica de seguridad. Ver Bloque 3 para el disparador de contratacion. | NO | PCI DSS v4.0.1, Req 12.6.3, p. 310 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.8.4 — Monitoreo del estado de cumplimiento PCI DSS de cada TPSP con quien se comparte datos de cuenta o que puede impactar la seguridad del CDE. Puede realizarse via AOC del TPSP, presencia en lista de marca de pago, u otro mecanismo. | NO | PCI DSS v4.0.1, Req 12.8.4, p. 318 LA |
| al menos una vez cada 12 meses (“anualmente”) | 12.10.2 — El plan de respuesta a incidentes es: (a) revisado y actualizado segun sea necesario, y (b) probado, incluyendo todos los elementos del Req 12.10.1. Dos actividades distintas: revision de contenido Y ejercicio/prueba. | NO | PCI DSS v4.0.1, Req 12.10.2, p. 327 LA |
| al menos una vez cada 12 meses (“anualmente”) | A3.1.1 (DESV) — Reporte a executive management y board sobre iniciativas de cumplimiento PCI DSS y actividades de remediacion. Solo Designated Entities (Apendice A3). | NO | PCI DSS v4.0.1, Req A3.1.1, p. 347 LA |
| al menos una vez cada 12 meses (“anualmente”) | A3.1.4 (DESV) — Capacitacion en PCI DSS/seguridad de la informacion para personal con responsabilidades de cumplimiento PCI DSS. Distinta de 12.6.3 (concientizacion general). Solo DESV. | NO | PCI DSS v4.0.1, Req A3.1.4, p. 350 LA |
| al menos una vez cada 12 meses (“anualmente”) | A3.2.5.1 (DESV) — Confirmacion de la efectividad de los metodos de data discovery (descubrimiento de PAN en texto claro). Solo DESV. Complementa A3.2.5 (trimestral). | NO | PCI DSS v4.0.1, Req A3.2.5.1, p. 358 LA |
| al menos una vez cada 12 meses (“anualmente”) | A3.3.2 (DESV) — Revision de tecnologias de hardware y software para confirmar que siguen cumpliendo los requisitos PCI DSS de la organizacion. Solo DESV. Similar a 12.3.4 con requisitos adicionales. | NO | PCI DSS v4.0.1, Req A3.3.2, p. 364 LA |
| al menos una vez cada seis meses | A3.4.1 (DESV) — Revision de cuentas de usuario y privilegios de acceso a componentes del sistema dentro del alcance. Solo DESV. Frecuencia semestral para DESV, igual que 7.2.4 para todos. | NO | PCI DSS v4.0.1, Req A3.4.1, p. 366 LA |
Mayor que 12 meses
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Dentro de los 36 meses anteriores | Secure SLC / Secure Software (Apendice A2) — Una evaluacion completa del lifecycle de desarrollo seguro debe haberse completado en los ultimos 36 meses. Este es un ciclo de validacion de programa, no un control operativo periodico. Solo aplica a entidades que validan mediante Secure SLC o Secure Software (PCI SSC software security frameworks). | NO | PCI DSS v4.0.1, Appendix A2, p. 341 LA |
Bloque 2 — Frecuencias definidas por la entidad mediante Análisis de Riesgo Específicos
Para estos requisitos, el estandar NO fija una frecuencia especifica. La entidad debe:
- Documentar una TRA conforme a Req 12.3.1.
- Justificar que la frecuencia elegida es adecuada para el riesgo.
- Revisar la TRA al menos anualmente (Req 12.3.1).
Si no existe TRA documentada para un requisito “periódicamente”, hay incumplimiento, independientemente de si la actividad se realizó.
| Marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 5.2.3 — Evaluacion periodica de componentes del sistema que no estan en riesgo de malware, para confirmar que siguen sin riesgo y que la evaluacion original sigue siendo valida. Si el componente pasa a estar en riesgo, se incluye en la determinación del alcance del anti-malware. | NO | PCI DSS v4.0.1, Req 5.2.3, p. 123 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 5.3.2.1 — Frecuencia de escaneos periodicos de malware. Solo aplica si la entidad usa escaneo periódico (no monitoreo continuo) para cumplir Req 5.3.2. Si la entidad tiene monitoreo continuo (en tiempo real), este requisito no aplica. | NO | PCI DSS v4.0.1, Req 5.3.2.1, p. 127 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 7.2.5.1 — Frecuencia de revision de cuentas de aplicacion y sistema, y sus privilegios de acceso. Distinto de 7.2.4 (cuentas de usuario: semestral fijo). La TRA determina la frecuencia adecuada para cuentas de aplicacion y sistema. | NO | PCI DSS v4.0.1, Req 7.2.5.1, p. 169 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 8.6.3 — Frecuencia de cambio de contrasenas/passphrases para cuentas de aplicacion y sistema. La complejidad requerida es proporcional a la frecuencia de cambio: a menor frecuencia, mayor complejidad. Adicionalmente, se cambia inmediatamente ante sospecha/confirmacion de compromiso. Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 8.6.3, p. 207 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 9.5.1.2.1 — Frecuencia y tipo de inspecciones de superficies de dispositivos POI. La TRA considera el entorno de despliegue, historial de ataques y perfil de riesgo. Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 10.4.2 — Frecuencia de revision de logs de componentes del sistema no cubiertos por 10.4.1 (que exige revision diaria). Alta prioridad: el examen distingue entre los logs criticos (10.4.1, diario fijo) y los demas logs (10.4.2, TRA). | NO | PCI DSS v4.0.1, Req 10.4.2, p. 248 LA; Req 10.4.2.1, p. 249 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 11.3.1.1 — Plazo para tratar vulnerabilidades de menor riesgo encontradas en escaneos internos. Las de alta/critica tienen tratamiento inmediato; las demas se tratan segun el riesgo definido en la TRA. El evaluador verifica tanto la TRA como la evidencia de que las vulns se trataron dentro del plazo definido. | NO | PCI DSS v4.0.1, Req 11.3.1.1, p. 267 LA |
| Al menos semanalmente o a la frecuencia definida en la TRA de la entidad | 11.6.1 — Mecanismo de deteccion de cambios y manipulacion en paginas de pago. La entidad elige entre ejecutar el mecanismo al menos semanalmente (frecuencia fija, Bloque 1) o a la frecuencia definida en su TRA (este bloque). Si elige la opcion TRA, la TRA debe justificar que la frecuencia es adecuada. Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 11.6.1, p. 287 LA |
| Definido por la entidad (TRA) — frecuencia justificada en análisis de riesgo específico, no fija en el estandar | 12.10.4.1 — Frecuencia de capacitacion periodica para personal de respuesta a incidentes. El tamaño y complejidad de la entidad, la rotacion de personal, y el grado de cambio del entorno son factores a considerar en la TRA. Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 12.10.4.1, p. 329 LA |
Bloque 3 — Actividades orientado por evento (disparadores, no calendario)
Estas actividades no tienen un ciclo fijo de calendario. Se ejecutan cuando ocurre el evento disparador. Cuando un requisito tambien tiene frecuencia fija (Bloque 1), se indica con nota cruzada.
Post Cambio Significativo (tras un cambio significativo)
Definicion de cambio significativo: nuevo HW/SW/red en el CDE, reemplazos o actualizaciones mayores en el CDE, cambios en flujo/almacenamiento de datos de cuenta, cambios en el limite del CDE o en la determinación del alcance, cambios en infraestructura de soporte del CDE (directory services, time servers, logging, monitoring), cambios en TPSPs que soportan el CDE. (PCI DSS v4.0.1, p. 25-26 LA)
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Antes o inmediatamente después de conectar un componente del sistema a producción | 2.2.1 — Aplicacion de configuration standards a nuevos sistemas: verificacion en vigor antes o inmediatamente despues de conectar el componente a produccion. Es un disparador de “nuevo sistema en el CDE”, no un ciclo periodico. Alta prioridad: el estandar acepta “antes o inmediatamente después”, lo que da flexibilidad operativa. | NO | PCI DSS v4.0.1, Req 2.2.1, p. 41 LA |
| Tras concluir un cambio significativo | 6.5.2 — Todos los requisitos PCI DSS aplicables confirmados como en vigor en los nuevos/modificados sistemas y redes tras completar el cambio. Los cambios deben capturarse en la confirmacion anual de determinación del alcance (12.5.2). Alta prioridad: el cambio tecnico no esta completo hasta que se verifico el cumplimiento PCI DSS. | NO | PCI DSS v4.0.1, Req 6.5.2, p. 155 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras cambios significativos | 6.4.1 (opcion evaluacion manual) — Evaluacion de seguridad de aplicaciones web publicas tambien se requiere tras cambio significativo. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 LA |
| Después de cualquier cambio significativo | 11.3.1.3 — Escaneos de vulnerabilidades internas despues de cualquier cambio significativo. No requiere autenticacion (distinto de 11.3.1.2). El escaneo post-cambio es parte del proceso de gestion de cambios. Nota cruzada: ver Bloque 1 sección trimestral para el ciclo ordinario. | NO | PCI DSS v4.0.1, Req 11.3.1.3, p. 269 LA |
| Después de cualquier cambio significativo | 11.3.2.1 — Escaneos de vulnerabilidades externos despues de cualquier cambio significativo. Puede ser realizado por recurso interno calificado o tercero externo (no requiere ASV a diferencia del trimestral 11.3.2). Nota cruzada: ver Bloque 1 sección trimestral. | NO | PCI DSS v4.0.1, Req 11.3.2.1, p. 272 LA |
| Tras cualquier actualización o cambio significativo de infraestructura o aplicación | 11.4.2 — Prueba de penetracion interna tambien se ejecuta tras cambio significativo. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 11.4.2, p. 276 LA |
| Tras cualquier actualización o cambio significativo de infraestructura o aplicación | 11.4.3 — Prueba de penetracion externa tambien se ejecuta tras cambio significativo. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 11.4.3, p. 277 LA |
| Tras cambios en controles o métodos de segmentación | 11.4.5 — Prueba de segmentación tambien se ejecuta tras cambios en los controles/metodos de segmentacion. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 11.4.5, p. 279 LA |
| Tras cambios en controles o métodos de segmentación | 11.4.6 — Prueba de segmentación (SP) tambien se ejecuta tras cambios. Solo SP. Nota cruzada: ver Bloque 1 sección semestral. | SI | PCI DSS v4.0.1, Req 11.4.6, p. 280 LA |
| al menos una vez cada 12 meses (“anualmente”) y tras un cambio significativo | 12.5.2 — Confirmacion de determinación del alcance tambien se realiza tras cambio significativo. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 12.5.2, p. 304 LA |
| al menos una vez cada seis meses y tras un cambio significativo | 12.5.2.1 — Confirmacion de determinación del alcance (SP) tambien se realiza tras cambio significativo. Solo SP. Nota cruzada: ver Bloque 1 sección semestral. | SI | PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA |
| al menos una vez cada tres meses (“trimestral”) y tras cambios significativos en el entorno dentro del alcance | A3.2.1 (DESV) — Confirmacion de determinación del alcance para Designated Entities. Frecuencia trimestral (la mas corta para confirmación de la determinación del alcance). Tambien tras cambio significativo. Solo DESV. | NO | PCI DSS v4.0.1, Req A3.2.1, p. 351 LA |
| al menos una vez cada tres meses (“trimestral”) y tras cambios significativos en el CDE o los procesos | A3.2.5 (DESV) — Data discovery de PAN en texto claro. La busqueda activa se ejecuta trimestralmente y tras cambio significativo en el CDE. Solo DESV. | NO | PCI DSS v4.0.1, Req A3.2.5, p. 357 LA |
Al contratar o al terminar la relación
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Al ingresar y al menos una vez cada 12 meses (“anualmente”) | 12.6.3 — Capacitacion en concientizacion de seguridad al contratar personal (disparador: hire) y anualmente (ver Bloque 1 sección anual). | NO | PCI DSS v4.0.1, Req 12.6.3, p. 310 LA |
| Inmediatamente al terminar la relación | 8.2.5 — Acceso logico revocado inmediatamente al terminar la relacion. Ver Bloque 1 sección “inmediato”. | NO | PCI DSS v4.0.1, Req 8.2.5, p. 181 LA |
| Inmediatamente al terminar la relación | 9.3.1.1 — Acceso fisico a areas sensibles revocado inmediatamente al terminar la relacion. Ver Bloque 1 sección “inmediato”. | NO | PCI DSS v4.0.1, Req 9.3.1.1, p. 217 LA |
Antes del despliegue
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Antes de liberarse a producción o a clientes | 6.2.3 — Revision de codigo de software a medida antes de liberar a produccion. El evaluador busca evidencia de que TODA liberacion fue revisada, no solo una muestra. | NO | PCI DSS v4.0.1, Req 6.2.3, p. 138 LA |
| Antes de liberarse a producción | 6.2.3.1 — Si se usan revisiones manuales de codigo: la revision la realiza un individuo distinto al autor del codigo. Separacion de funciones obligatoria. | NO | PCI DSS v4.0.1, Req 6.2.3.1, p. 138 LA |
| Antes del despliegue | Implicito en 6.5.2 — Para cambios que califican como cambio significativo, los requisitos PCI DSS deben verificarse antes (idealmente) o al completar el cambio. | NO | PCI DSS v4.0.1, Req 6.5.2, p. 155 LA |
Ante sospecha o confirmación de compromiso
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Ante sospecha o confirmación de compromiso | 8.6.3 — Contrasenas/passphrases de cuentas de aplicacion y sistema cambiadas inmediatamente ante sospecha/confirmacion de compromiso. La frecuencia ordinaria es definida por TRA (ver Bloque 2). Activo a partir del 31 de marzo de 2025. | NO | PCI DSS v4.0.1, Req 8.6.3, p. 207 LA |
| Inmediatamente | 12.10 — Incidentes de seguridad sospechados o confirmados que impactan el CDE se responden inmediatamente. El plan de respuesta a incidentes (12.10.1) debe estar listo para activarse. El testing del plan es anual (12.10.2, Bloque 1). | NO | PCI DSS v4.0.1, Req 12.10, p. 289 LA |
Al detectar una falla de control de seguridad crítico
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Con prontitud al detectarse una falla | 10.7.2 — Deteccion y alerta inmediata de fallas de sistemas de control de seguridad criticos (todos desde 31 marzo 2025). Ver Bloque 1 sección “inmediato/con prontitud”. | NO | PCI DSS v4.0.1, Req 10.7.2, p. 256 LA |
| Con prontitud | 10.7.3 — Respuesta y documentacion de fallas de controles de seguridad criticos. Ver Bloque 1 sección “inmediato/con prontitud”. | NO | PCI DSS v4.0.1, Req 10.7.3, p. 257 LA |
Primer uso
| Disparador o marco temporal (PDF LA) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Inmediatamente después del primer uso | 8.3.5 — Contrasena/passphrase cambiada inmediatamente en el primer inicio de sesion tras ser asignada o reseteada. Ver Bloque 1 sección “inmediato”. | NO | PCI DSS v4.0.1, Req 8.3.5, p. 193 LA |
Tabla resumen ejecutivo — Frecuencias por requisito (referencia rapida)
| Frecuencia | Requisitos clave |
|---|---|
| Inmediato | 8.2.5, 8.3.5, 9.3.1.1, 10.7.2, 10.7.3 |
| Diario | 10.4.1 |
| Semanal (min.) | 11.6.1 |
| 90 dias | 8.3.9 (calendario), 8.2.6 (inactividad) |
| Trimestral | 3.2.1, 11.2.1, 11.3.1, 11.3.2, 12.4.2 (SP) |
| Semestral | 1.2.7, 7.2.4, 11.4.6 (SP), 12.5.2.1 (SP), A1.1.4 (SP multi-tenant) |
| Anual | 6.2.2, 9.4.1.2, 9.4.5.1, 11.4.2, 11.4.3, 11.4.5, 12.1.1, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.5.2, 12.6.2, 12.6.3, 12.8.4, 12.10.2 |
| TRA | 5.2.3, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2, 11.3.1.1, 11.6.1 (alt.), 12.10.4.1 |
| Post-cambio significativo | 6.5.2, 11.3.1.3, 11.3.2.1, 11.4.2, 11.4.3, 11.4.5, 11.4.6 (SP), 12.5.2, 12.5.2.1 (SP) |
| DESV (A3) | A3.2.1 (trimestral + cambio significativo), A3.2.5 (trimestral + cambio significativo), A3.1.1 (anual), A3.1.4 (anual), A3.2.5.1 (anual), A3.3.2 (anual), A3.3.3 (trimestral), A3.4.1 (semestral) |
Fuentes consultadas
- PCI DSS v4.0.1: Requisitos y Procedimientos de Evaluación, versión 4.0.1, junio de 2024, PCI Security Standards Council. Fuente local:
docs/es/PCI-DSS-v4_0_1-LA.pdf.- Sección “Description of Timeframes Used in PCI DSS Requirements”, p. 25-27 LA.
- Sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21 LA.
- Todos los requisitos citados en los tres bloques anteriores.
- Appendix A1 (Requisitos adicionales para proveedores de servicios multiusuario), p. 337 LA.
- Appendix A3 (Designated Entities Supplemental Validation — DESV), p. 345-366 LA.
- Links de referencia PCI SSC:
docs/links-pci.txt.