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 targeted risk analysis (TRA — Req 12.3.1). El estándar dice “periodically”.
- Bloque 3: actividades event-driven — 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).
Bloque 1 — Frecuencias fijas por el estándar
Orden: inmediato → dentro de 24 h → diario → semanal → 90 días → trimestral → semestral → anual → mayor.
Inmediato / Sin demora (Immediately / Promptly)
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Immediately / Inmediato | 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 |
| Immediately / Inmediato | 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 |
| Immediately / Inmediato | 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 |
| Promptly upon detection / Prontamente al detectar | 10.7.2 — Fallas de sistemas de control de seguridad criticos detectadas, alertadas y tratadas prontamente (NSC, IDS/IPS, change-detection, anti-malware, audit log, segmentation controls). Activo a partir del 31 de marzo de 2025 para todos. | NO | PCI DSS v4.0.1, Req 10.7.2, p. 256 |
| Promptly upon detection / Prontamente al detectar | 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 |
| Immediately investigated / 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 + sig change (ver sección anual). | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 |
Daily / Diario
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| At least once daily / Al menos una vez al dia | 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. “Daily” = todos los dias del año, no solo dias habiles. Alta prioridad: la falta de revision diaria es hallazgo critico en un assessment. Ver 10.4.2 para logs de otros componentes (frecuencia por TRA). | NO | PCI DSS v4.0.1, Req 10.4.1, p. 246 |
At least weekly / Al menos semanal
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| At least weekly / Al menos semanalmente (minimo) | 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 change-detection 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 |
Within 90 days of inactivity / Dentro de los 90 dias de inactividad
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Within 90 days of inactivity / Dentro de los 90 dias de inactividad | 8.2.6 — Cuentas de usuario inactivas removidas o deshabilitadas. Trigger: 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 |
| At least once every 90 days / Al menos cada 90 dias | 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 |
At least once every three months / Al menos trimestral
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| at least once every three months / al menos una vez cada tres meses | 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 |
| at least once every three months / al menos una vez cada tres meses | 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 |
| at least once every three months / al menos una vez cada tres meses | 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 |
| at least once every three months / al menos una vez cada tres meses | 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 |
| at least once every three months / al menos una vez cada tres meses | 11.3.2 — Escaneos de vulnerabilidades externas por un PCI SSC Approved Scanning Vendor (ASV). El resultado debe ser un “passing scan”. 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 significant change). | NO | PCI DSS v4.0.1, Req 11.3.2, p. 270 |
| at least once every three months / al menos una vez cada tres meses | 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 service providers. | SI | PCI DSS v4.0.1, Req 12.4.2, p. 301 |
At least once every six months / Al menos semestral
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| at least once every six months / 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 |
| at least once every six months / 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 |
| at least once every six months and after any changes to segmentation controls/methods / al menos cada seis meses y tras cambios en segmentacion | 11.4.6 — Testing de controles de segmentacion para service providers que usan segmentacion. Frecuencia semestral vs. anual para entidades no SP (11.4.5). Solo aplica a service providers. Ver Bloque 3 para el trigger de cambio en controles/metodos de segmentacion. | SI | PCI DSS v4.0.1, Req 11.4.6, p. 280 |
| at least once every six months and upon significant change / al menos cada seis meses y tras sig. change | 12.5.2.1 — Confirmacion del scope PCI DSS para service providers. Frecuencia semestral vs. anual para otros (12.5.2). Tambien se confirma tras significant change. Solo aplica a service providers. Ver Bloque 3 para el trigger de significant change. | SI | PCI DSS v4.0.1, Req 12.5.2.1, p. 306 |
| at least once every six months via penetration testing / al menos cada seis meses mediante pen test | A1.1.4 — Confirmacion de la efectividad de controles de separacion logica entre entornos de clientes en SP multi-tenant mediante pen test. Adicional a los pen tests de 11.4.6. Solo aplica a multi-tenant service providers (Apendice A1). | SI | PCI DSS v4.0.1, Req A1.1.4, p. 337 |
At least once every 12 months / Al menos anual
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| at least once every 12 months / al menos una vez cada 12 meses | 6.2.2 — Capacitacion en codificacion segura para personal de desarrollo de software a medida (bespoke and custom software). 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 |
| at least once every 12 months and after significant changes / al menos anual y tras sig. change | 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 trigger de significant change. | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 9.4.5.1 — Inventario de medios electronicos con CHD. El assessor 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 |
| at least once every 12 months and after any significant infrastructure or application upgrade or change / al menos anual y tras cambio significativo | 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 trigger de significant change. | NO | PCI DSS v4.0.1, Req 11.4.2, p. 276 |
| at least once every 12 months and after any significant infrastructure or application upgrade or change / al menos anual y tras cambio significativo | 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 trigger de significant change. | NO | PCI DSS v4.0.1, Req 11.4.3, p. 277 |
| at least once every 12 months and after any changes to segmentation controls/methods / al menos anual y tras cambios en controles de segmentacion | 11.4.5 — Testing 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 trigger de cambio en controles/metodos de segmentacion. | NO | PCI DSS v4.0.1, Req 11.4.5, p. 279 |
| at least once every 12 months / al menos una vez al año | 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 |
| Review at least once every 12 months / Revision al menos una vez al año | 12.3.1 — Revision de cada TRA al menos anualmente para determinar si los resultados siguen siendo validos. Meta-requisito: toda actividad “periodically” 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 |
| at least once every 12 months / al menos una vez al año | 12.3.2 — TRA para cada control implementado mediante Customized Approach, revisada al menos anualmente. Solo aplica si la entidad usa el Customized Approach. | NO | PCI DSS v4.0.1, Req 12.3.2, p. 297 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months and upon significant change / al menos anual y tras significant change | 12.5.2 — Confirmacion y documentacion del scope 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 trigger de significant change. | NO | PCI DSS v4.0.1, Req 12.5.2, p. 304 |
| Reviewed at least once every 12 months / Revisado al menos una vez al año | 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 |
| Upon hire and at least once every 12 months / Al ingresar y al menos una vez al año | 12.6.3 — Capacitacion en concientizacion de seguridad para todo el personal. Doble trigger: al ingresar (event-driven) y anualmente (calendario). El personal debe reconocer al menos anualmente haber leido y entendido la politica de seguridad. Ver Bloque 3 para el trigger de contratacion. | NO | PCI DSS v4.0.1, Req 12.6.3, p. 310 |
| at least once every 12 months / al menos una vez al año | 12.8.4 — Monitoreo del estado de cumplimiento PCI DSS de cada TPSP con quien se comparte account data 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every 12 months / al menos una vez al año | 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 |
| at least once every six months / al menos cada seis meses | A3.4.1 (DESV) — Revision de cuentas de usuario y privilegios de acceso a componentes del sistema en scope. 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 |
Mayor que 12 meses
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Within the previous 36 months / 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 |
Bloque 2 — Frecuencias definidas por la entidad mediante Targeted Risk Analysis
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 “periodically”, hay incumplimiento, independientemente de si la actividad se realizó.
| Marco temporal (PDF / español) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 el scope del anti-malware. | NO | PCI DSS v4.0.1, Req 5.2.3, p. 123 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, no fija en el estandar | 5.3.2.1 — Frecuencia de escaneos periodicos de malware. Solo aplica si la entidad usa periodic scanning (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 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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; Req 10.4.2.1, p. 249 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 assessor 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 |
| At least weekly OR at the frequency defined in the entity’s TRA / Al menos semanal O a la frecuencia de la TRA | 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 |
| Definido por la entidad (TRA) — frecuencia justificada en analisis de riesgo targeted, 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 |
Bloque 3 — Actividades event-driven (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 Significant Change (tras un cambio significativo)
Definicion de significant change: nuevo HW/SW/red en el CDE, reemplazos o actualizaciones mayores en el CDE, cambios en flujo/almacenamiento de account data, cambios en el limite del CDE o en el scope, 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)
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Before or immediately after a system component is connected to production / Antes o inmediatamente despues de conectar un componente a produccion | 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 trigger de “nuevo sistema en el CDE”, no un ciclo periodico. Alta prioridad: el estandar acepta “before OR immediately after”, lo que da flexibilidad operativa. | NO | PCI DSS v4.0.1, Req 2.2.1, p. 41 |
| Upon completion of a significant change / Al completar un significant change | 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 scope (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 |
| At least once every 12 months AND after significant changes / Al menos anual Y tras significant changes | 6.4.1 (opcion evaluacion manual) — Evaluacion de seguridad de aplicaciones web publicas tambien se requiere tras significant change. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 6.4.1, p. 149 |
| After any significant change / Despues de cualquier significant change | 11.3.1.3 — Escaneos de vulnerabilidades internas despues de cualquier significant change. 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 |
| After any significant change / Despues de cualquier significant change | 11.3.2.1 — Escaneos de vulnerabilidades externos despues de cualquier significant change. 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 |
| After any significant infrastructure or application upgrade or change / Tras cualquier actualizacion o cambio significativo de infraestructura o aplicacion | 11.4.2 — Prueba de penetracion interna tambien se ejecuta tras significant change. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 11.4.2, p. 276 |
| After any significant infrastructure or application upgrade or change / Tras cualquier actualizacion o cambio significativo | 11.4.3 — Prueba de penetracion externa tambien se ejecuta tras significant change. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 11.4.3, p. 277 |
| After any changes to segmentation controls or methods / Tras cambios en controles de segmentacion | 11.4.5 — Testing de segmentacion 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 |
| After any changes to segmentation controls or methods / Tras cambios en controles de segmentacion | 11.4.6 — Testing de segmentacion (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 |
| At least once every 12 months AND upon significant change / Al menos anual Y tras significant change | 12.5.2 — Confirmacion de scope tambien se realiza tras significant change. Nota cruzada: ver Bloque 1 sección anual. | NO | PCI DSS v4.0.1, Req 12.5.2, p. 304 |
| At least once every six months AND upon significant change / Al menos semestral Y tras significant change | 12.5.2.1 — Confirmacion de scope (SP) tambien se realiza tras significant change. Solo SP. Nota cruzada: ver Bloque 1 sección semestral. | SI | PCI DSS v4.0.1, Req 12.5.2.1, p. 306 |
| At least once every three months AND upon significant changes to in-scope environment / Trimestral Y tras significant changes | A3.2.1 (DESV) — Confirmacion de scope para Designated Entities. Frecuencia trimestral (la mas corta para scope confirmation). Tambien tras significant change. Solo DESV. | NO | PCI DSS v4.0.1, Req A3.2.1, p. 351 |
| At least once every three months AND upon significant changes to CDE or processes / Trimestral Y tras cambios en CDE o procesos | A3.2.5 (DESV) — Data discovery de PAN en texto claro. La busqueda activa se ejecuta trimestralmente y tras significant change en el CDE. Solo DESV. | NO | PCI DSS v4.0.1, Req A3.2.5, p. 357 |
Al contratar o al terminar la relacion (Hire / Termination)
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Upon hire and at least once every 12 months / Al contratar y al menos anualmente | 12.6.3 — Capacitacion en concientizacion de seguridad al contratar personal (trigger: hire) y anualmente (ver Bloque 1 sección anual). | NO | PCI DSS v4.0.1, Req 12.6.3, p. 310 |
| Immediately upon termination / Inmediatamente al terminar | 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 |
| Immediately upon termination / Inmediatamente al terminar | 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 |
Antes del despliegue / Prior to release
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Prior to being released into production or to customers / Antes de liberarse a produccion o a clientes | 6.2.3 — Revision de codigo de software a medida antes de liberar a produccion. El assessor busca evidencia de que TODA liberacion fue revisada, no solo una muestra. | NO | PCI DSS v4.0.1, Req 6.2.3, p. 138 |
| Prior to release to production / Antes de liberarse a produccion (si se usa revision manual) | 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 |
| Before deployment / Antes del despliegue | Implicito en 6.5.2 — Para cambios que califican como significant change, 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 |
Upon suspected or confirmed compromise / Ante sospecha o confirmacion de compromiso
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Upon suspicion or confirmation of compromise / Ante sospecha o confirmacion 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 |
| Immediately / 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 |
Upon detection of failure / Al detectar falla de control de seguridad critico
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Promptly upon detection of failure / Prontamente al detectar la 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/promptly”. | NO | PCI DSS v4.0.1, Req 10.7.2, p. 256 |
| Promptly / Prontamente | 10.7.3 — Respuesta y documentacion de fallas de controles de seguridad criticos. Ver Bloque 1 sección “inmediato/promptly”. | NO | PCI DSS v4.0.1, Req 10.7.3, p. 257 |
First use / Primer uso
| Disparador / Marco temporal (PDF) | Requisito y descripcion | Solo SP | Fuente |
|---|---|---|---|
| Immediately after first use / Inmediatamente despues 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 |
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 sig. change / post cambio | 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 + sig change), A3.2.5 (trimestral + sig change), 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: Requirements and Testing Procedures, Version 4.0.1, June 2024, PCI Security Standards Council. Fuente local:
docs/PCI-DSS-v4_0_1.pdf.- Sección “Description of Timeframes Used in PCI DSS Requirements”, p. 25-27.
- Sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21.
- Todos los requisitos citados en los tres bloques anteriores.
- Appendix A1 (Additional Requirements for Multi-Tenant Service Providers), p. 337.
- Appendix A3 (Designated Entities Supplemental Validation — DESV), p. 345-366.
- Links de referencia PCI SSC:
docs/links-pci.txt.