Periodicidad, BAU y Cambio Significativo — Vista por Requisito

Vista “qué/cómo” de los controles recurrentes de PCI DSS v4.0.1. Complemento de recurring-activities-by-timeframe.md (vista “cuándo”). Cada tabla referencia al otro archivo.

Cómo leer esta tabla

Periodicidad: frecuencia exacta que exige el estándar (terminología del PDF).
BAU: clasificacion pedagogica/operativa de esta guia. SI si la actividad normalmente forma parte del monitoreo continuo y las operaciones diarias de seguridad; NO si es una evaluacion puntual o de cumplimiento periodico. No es un campo formal del estandar.
Cambio Significativo: SI si el requisito también se dispara tras un cambio significativo, independientemente del calendario.
TRA: SI si la frecuencia no está fija en el estándar y la define la entidad mediante análisis de riesgo específicos (Req 12.3.1).
Solo SP: SI si el requisito aplica exclusivamente a proveedores de servicio.

Error común de examen: “periodic” en PCI DSS no significa necesariamente anual. Ver definiciones en (PCI DSS v4.0.1, sección “Description of Timeframes Used”, p. 25 LA).

Definiciones clave de marcos temporales (PCI DSS v4.0.1, p. 25 LA)

Término en el PDF	Equivalente normalizado
Diario	Diario — todos los días del año, incluyendo fines de semana
Semanalmente	Semanal — al menos una vez cada 7 días
Cada 30 días	Mensual — al menos cada 30-31 días
Cada tres meses (“trimestral”)	Trimestral — al menos cada 90-92 días
Cada seis meses	Semestral — al menos cada 180-184 días
Cada 12 meses (“anualmente”)	Anual — al menos cada 365/366 días
Periódicamente	Definido por la entidad, soportado por TRA (Req 12.3.1)
Inmediatamente	Sin demora, en tiempo real o casi real
Con prontitud	Lo antes que sea razonablemente posible

Alta prioridad para examen: los distractores juegan con diferencias entre “every 90 days” y “every three months” (son equivalentes), o entre “every 12 months” y “annually” (también equivalentes). Ver recurring-activities-by-timeframe.md Bloque 1.

Definición de Cambio Significativo (PCI DSS v4.0.1, p. 25-26 LA)

Constituye cambio significativo, como mínimo, cualquiera de los siguientes:

Nuevo hardware, software o equipamiento de red agregado al CDE.
Reemplazo o actualizaciones mayores de hardware/software en el CDE.
Cambios en el flujo o almacenamiento de datos de cuenta.
Cambios en el límite del CDE o en la determinación del alcance de la evaluación PCI DSS.
Cambios en la infraestructura de soporte subyacente del CDE (incluyendo directory services, time servers, logging, monitoring).
Cambios en terceros/proveedores de servicio que soportan el CDE o cumplen requisitos PCI DSS en nombre de la entidad.

Lo que constituye un cambio significativo depende del entorno específico de la entidad. La entidad define qué cambios califican para cada requisito relacionado.

Tabla principal — Controles recurrentes por requisito

Req	Descripcion breve	Periodicidad exacta (PDF)	BAU	Cambio signif.	TRA	Solo SP	Notas para examen	Fuente
1.2.7	Revision de configuraciones de NSC	al menos una vez cada seis meses	SI	NO	NO	NO	El examen distingue entre esta revision (semestral) y la revision de 12.4.2 (SP trimestral). No confundir NSC ruleset review con firewall change management.	PCI DSS v4.0.1, Req 1.2.7, p. 48 LA
2.2.1	Aplicacion de configuration standards a nuevos sistemas	antes o inmediatamente después de conectar un componente del sistema a un entorno de producción	SI	SI	NO	NO	Disparador: conexion de nuevo sistema a produccion. No es periodico; es orientado por evento. Alta prioridad: los distractores sugieren que aplica solo en produccion establecida.	PCI DSS v4.0.1, Req 2.2.1, p. 41 LA
3.2.1	Verificacion de que datos de cuenta no excede retencion definida y es eliminada de forma segura	al menos una vez cada tres meses (“trimestral”)	SI	NO	NO	NO	La entidad debe tener un proceso que se ejecute al menos trimestralmente para verificar y eliminar datos que superan el periodo de retencion. Alta prioridad: distinguir entre retener datos (permitido si hay justificacion) y no verificar el cumplimiento del proceso (incumplimiento).	PCI DSS v4.0.1, Req 3.2.1, p. 76 LA
5.2.3	Evaluacion periodica de componentes del sistema no en riesgo de malware	Periódicamente (TRA)	SI	NO	SI	NO	Requiere TRA para definir frecuencia. Los componentes sin riesgo deben evaluarse igualmente para confirmar que siguen sin riesgo. Error comun: asumir que “no en riesgo” equivale a exento permanente.	PCI DSS v4.0.1, Req 5.2.3, p. 123 LA
5.3.2.1	Frecuencia de escaneos periodicos de malware	Periódicamente (TRA)	SI	NO	SI	NO	Aplica solo si la entidad usa escaneos periódicos (en lugar de monitoreo continuo). La frecuencia la define la TRA. El examen puede preguntar si la TRA es suficiente para justificar la frecuencia elegida.	PCI DSS v4.0.1, Req 5.3.2.1, p. 127 LA
6.2.2	Capacitacion en codificacion segura para desarrolladores de software a medida	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Aplica a personal que desarrolla software a medida y personalizado. No aplica a COTS. Alta prioridad: distinguir entre la capacitacion inicial y la recurrente anual.	PCI DSS v4.0.1, Req 6.2.2, p. 137 LA
6.2.3	Revision de codigo antes de liberarse a produccion	antes de liberarse a producción o a clientes	SI	NO	NO	NO	Disparador: pre-release. No es periodico; es orientado por evento. Se requiere para todo software a medida y personalizado. El evaluador busca evidencia de que toda liberacion paso por revision.	PCI DSS v4.0.1, Req 6.2.3, p. 138 LA
6.2.3.1	Revisiones manuales de codigo: revisadas y aprobadas por individuo distinto al autor	antes de liberarse a producción	SI	NO	NO	NO	Solo aplica si la entidad usa revisiones manuales de codigo. Requiere separacion de funciones (quien escribe no puede aprobar).	PCI DSS v4.0.1, Req 6.2.3.1, p. 138 LA
6.4.1	Evaluacion de seguridad de aplicaciones web publicas O solucion automatizada continua (WAF/AST)	Opcion A: al menos una vez cada 12 meses (“anualmente”) y tras cambios significativos	SI	SI (si opcion A)	NO	NO	Alta prioridad: la entidad elige entre dos opciones: (A) evaluacion anual por especialista en seguridad de aplicaciones + tras cambio significativo, o (B) solucion automatizada continua con alertas investigadas inmediatamente. No se pueden mezclar parcialmente.	PCI DSS v4.0.1, Req 6.4.1, p. 149 LA
6.5.2	Confirmacion de cumplimiento de todos los requisitos PCI DSS aplicables tras cambio significativo	Tras concluir un cambio significativo	SI	SI	NO	NO	Disparador: cierre de un cambio significativo. El cambio debe capturarse en la confirmacion anual de determinación del alcance (Req 12.5.2). Alta prioridad: el examen puede preguntar si basta con completar el cambio tecnico sin verificar el impacto en PCI DSS.	PCI DSS v4.0.1, Req 6.5.2, p. 155 LA
7.2.4	Revision de todas las cuentas de usuario y privilegios de acceso (incluyendo terceros/vendors)	al menos una vez cada seis meses	SI	NO	NO	NO	Incluye cuentas de terceros. Distinguir de 7.2.5.1 (cuentas de aplicacion/sistema, frecuencia por TRA). La revision debe confirmar que el acceso es apropiado para la funcion del usuario.	PCI DSS v4.0.1, Req 7.2.4, p. 167 LA
7.2.5.1	Revision de cuentas de aplicacion y sistema y sus privilegios	Periódicamente (TRA)	SI	NO	SI	NO	Frecuencia definida por TRA. Distinto de 7.2.4 (cuentas de usuario, semestral fijo). Los evaluadores verifican tanto la TRA como la evidencia de revision.	PCI DSS v4.0.1, Req 7.2.5.1, p. 169 LA
8.2.5	Revocacion inmediata de acceso de usuarios terminados	Inmediatamente al terminar la relación	SI	NO	NO	NO	Orientado por evento: terminacion del usuario. “Inmediatamente” = sin demora. El examen puede preguntar que sucede si el proceso tarda horas o dias — incumplimiento. BAU critico.	PCI DSS v4.0.1, Req 8.2.5, p. 181 LA
8.2.6	Desactivacion de cuentas inactivas dentro de 90 dias	Dentro de 90 días de inactividad	SI	NO	NO	NO	Disparador: inactividad de la cuenta. No es un proceso periodico de calendario, sino uno basado en la deteccion de inactividad. Las cuentas inactivas son vectores de ataque frecuentes.	PCI DSS v4.0.1, Req 8.2.6, p. 182 LA
8.3.5	Cambio de contrasena/passphrase en primer uso	Inmediatamente después del primer uso	SI	NO	NO	NO	Disparador: primer inicio de sesion. Se aplica a cuentas recien creadas o reseteadas. Error comun: asumir que el sistema lo gestiona automaticamente sin verificar evidencia.	PCI DSS v4.0.1, Req 8.3.5, p. 193 LA
8.3.9	Cambio de contrasena/passphrase al menos cada 90 dias (si es el unico factor de autenticacion)	al menos una vez cada 90 días o análisis dinámico de postura de seguridad	SI	NO	NO	NO	Aplica SOLO cuando la contrasena es el unico factor de autenticacion (implementacion de single-factor). Si hay MFA, este requisito no aplica de la misma forma. Alta prioridad: el examen distingue entre cuentas con MFA y sin MFA.	PCI DSS v4.0.1, Req 8.3.9, p. 192 LA
8.6.3	Cambio periodico de contrasenas de cuentas de aplicacion y sistema; proteccion contra mal uso	Periódicamente (TRA) y ante sospecha o confirmación de compromiso	SI	NO	SI	NO	Doble disparador: TRA para la frecuencia ordinaria + inmediato ante sospecha/confirmacion de compromiso. Distinguir de 8.3.9 (cuentas de usuario, 90 dias fijo). Req activo a partir del 31 de marzo de 2025.	PCI DSS v4.0.1, Req 8.6.3, p. 207 LA
9.3.1.1	Revocacion inmediata de acceso fisico a areas sensibles al terminar relacion	Inmediatamente al terminar la relación	SI	NO	NO	NO	Incluye devolucionar o deshabilitar todos los mecanismos de acceso fisico (llaves, tarjetas, etc.). Paralelo a 8.2.5 para acceso logico.	PCI DSS v4.0.1, Req 9.3.1.1, p. 217 LA
9.4.1.2	Revision de seguridad de la ubicacion de backup de medios fisicos offline con CHD	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	El revisor visita o evalua la ubicacion de almacenamiento de respaldos offline. Distincion: esto es una evaluacion de seguridad fisica, no una auditoria logica.	PCI DSS v4.0.1, Req 9.4.1.2, p. 221 LA
9.4.5.1	Inventario de medios electronicos con CHD	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Inventario fisico de medios. El evaluador verifica logs del inventario y evidencia de conteos. Alta prioridad: distinguir entre inventario (anual) y clasificacion (permanente, Req 9.4.2).	PCI DSS v4.0.1, Req 9.4.5.1, p. 224 LA
9.5.1.2	Inspeccion periodica de superficies de dispositivos POI	Periódicamente	SI	NO	NO	NO	Req “padre”; la frecuencia especifica la define 9.5.1.2.1 mediante TRA. El tipo e inspeccion incluyen verificacion visual de signos de manipulacion.	PCI DSS v4.0.1, Req 9.5.1.2, p. 230 LA
9.5.1.2.1	Frecuencia e tipo de inspecciones de dispositivos POI	Periódicamente (TRA)	SI	NO	SI	NO	La TRA define la frecuencia e tipo de inspeccion. Req activo a partir del 31 de marzo de 2025. El examen puede preguntar por la diferencia entre la obligacion de inspeccionar (9.5.1.2) y la TRA para la frecuencia (9.5.1.2.1).	PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA
10.4.1	Revision diaria de logs de eventos de seguridad, alertas IDS/IPS, sistemas criticos y sistemas criptograficos criticos	al menos una vez al día	SI	NO	NO	NO	Alta prioridad: “diario” = todos los dias, no solo dias habiles. El examen distingue entre 10.4.1 (diario, logs criticos) y 10.4.2 (periodico TRA, logs de otros componentes). La ausencia de revision diaria es hallazgo critico.	PCI DSS v4.0.1, Req 10.4.1, p. 246 LA
10.4.2	Revision periodica de logs de otros componentes del sistema (no cubiertos por 10.4.1)	Periódicamente (TRA)	SI	NO	SI	NO	La frecuencia la define la entidad via TRA (Req 10.4.2.1). Distincion clara con 10.4.1: los logs “otros” no requieren revision diaria sino a la frecuencia justificada por riesgo.	PCI DSS v4.0.1, Req 10.4.2, p. 248 LA; Req 10.4.2.1, p. 249 LA
10.5.1	Retencion de historial de audit logs al menos 12 meses; 3 meses inmediatamente disponibles	Retener al menos 12 meses; los 3 meses más recientes disponibles inmediatamente	SI	NO	NO	NO	Alta prioridad: dos requisitos en uno — retencion total (12 meses) y acceso rapido (3 meses en linea/inmediato). “Disponibles inmediatamente” significa sin necesidad de procesos de restauracion lentos.	PCI DSS v4.0.1, Req 10.5.1, p. 251 LA
10.7.1	Deteccion y respuesta a fallas de sistemas de control de seguridad criticos (Solo SP hasta marzo 2025)	Con prontitud al detectarse una falla	SI	NO	NO	SI	Aplica SOLO a proveedores de servicio hasta el 31 de marzo de 2025; reemplazado por 10.7.2 para todos desde esa fecha.	PCI DSS v4.0.1, Req 10.7.1, p. 254 LA
10.7.2	Deteccion y respuesta a fallas de sistemas de control de seguridad criticos (todos desde marzo 2025)	Con prontitud al detectarse una falla	SI	NO	NO	NO	Incluye NSC, IDS/IPS, mecanismos de detección de cambios, anti-malware, audit log, controles de segmentación, soluciones de revisión de logs de auditoría, herramientas automatizadas de pruebas de seguridad. Activo a partir del 31 de marzo de 2025.	PCI DSS v4.0.1, Req 10.7.2, p. 256 LA
10.7.3	Respuesta a fallas de sistemas de control de seguridad criticos	Con prontitud al detectarse	SI	NO	NO	NO	Requiere documentar: causa, duracion de la falla, acciones correctivas. Distincion: 10.7.2 es deteccion/alerta; 10.7.3 es el proceso de respuesta y documentacion.	PCI DSS v4.0.1, Req 10.7.3, p. 257 LA
11.2.1	Deteccion y testing de puntos de acceso inalambrico no autorizados	al menos una vez cada tres meses (“trimestral”)	SI	NO	NO	NO	El proceso de deteccion puede ser automatizado (monitoreo continuo) o manual (testing trimestral). Si es automatizado y continuo, cumple el requisito.	PCI DSS v4.0.1, Req 11.2.1, p. 262 LA
11.3.1	Escaneos de vulnerabilidades internas	al menos una vez cada tres meses (“trimestral”)	SI	NO	NO	NO	Alta prioridad: escaneos internos no requieren ASV. 11.3.1.2 (requerimiento adicional): escaneos con autenticacion. Distinguir de 11.3.2 (externos, requieren ASV).	PCI DSS v4.0.1, Req 11.3.1, p. 265 LA
11.3.1.1	Tratamiento de vulnerabilidades de menor riesgo encontradas en escaneos internos	Periódicamente (TRA) — según riesgo	SI	NO	SI	NO	Las vulnerabilidades criticas/alta deben corregirse; las de menor riesgo se tratan segun el riesgo definido en la TRA. Alta prioridad: no todas las vulnerabilidades tienen el mismo tratamiento.	PCI DSS v4.0.1, Req 11.3.1.1, p. 267 LA
11.3.1.2	Escaneos internos autenticados	al menos una vez cada tres meses (“trimestral”)	NO	NO	NO	NO	Es el metodo obligatorio para realizar los escaneos internos de 11.3.1 (mejor práctica hasta 31 marzo 2025, luego obligatorio). Los escaneos autenticados revelan mas vulnerabilidades que los no autenticados.	PCI DSS v4.0.1, Req 11.3.1.2, p. 268 LA
11.3.1.3	Escaneos de vulnerabilidades internas despues de cambio significativo	Después de cualquier cambio significativo	SI	SI	NO	NO	No requiere autenticacion (11.3.1.2 no aplica a escaneos post-cambio). El proceso de escaneo post-cambio debe ser parte del proceso de gestion de cambios.	PCI DSS v4.0.1, Req 11.3.1.3, p. 269 LA
11.3.2	Escaneos de vulnerabilidades externas (ASV)	al menos una vez cada tres meses (“trimestral”)	SI	NO	NO	NO	Alta prioridad: DEBE ser realizado por un PCI SSC Approved Scanning Vendor (ASV). Distinguir de 11.3.1 (interno, no requiere ASV). El resultado debe ser “análisis aprobado”.	PCI DSS v4.0.1, Req 11.3.2, p. 270 LA
11.3.2.1	Escaneos de vulnerabilidades externas despues de cambio significativo	Después de cualquier cambio significativo	SI	SI	NO	NO	Puede ser realizado por recurso interno calificado o tercero externo. No requiere ASV para el escaneo post-cambio (a diferencia del trimestral).	PCI DSS v4.0.1, Req 11.3.2.1, p. 272 LA
11.4.1	Metodologia de pruebas de penetración definida, documentada e implementada	Según la metodología; resultados y remediación retenidos al menos 12 meses	NO	NO	NO	NO	No es la ejecucion del prueba de penetración. Define cobertura, pruebas internas/externas, segmentacion, capa aplicacion/red, amenazas de los ultimos 12 meses, gestion de hallazgos y retencion de resultados/remediacion por al menos 12 meses.	PCI DSS v4.0.1, Req 11.4.1, p. 274 LA
11.4.2	Prueba de penetracion interna	al menos una vez cada 12 meses (“anualmente”) y tras cualquier actualización o cambio significativo de infraestructura o aplicación	NO	SI	NO	NO	Simula ataque desde dentro de la red. Debe seguir la metodologia de 11.4.1 y ser realizada por recurso calificado con independencia organizacional; no requiere QSA ni ASV.	PCI DSS v4.0.1, Req 11.4.2, p. 276 LA
11.4.3	Prueba de penetracion externa	al menos una vez cada 12 meses (“anualmente”) y tras cualquier actualización o cambio significativo de infraestructura o aplicación	NO	SI	NO	NO	Simula ataque desde fuera de la red. Misma frecuencia que 11.4.2 y debe seguir la metodologia de 11.4.1; no requiere QSA ni ASV.	PCI DSS v4.0.1, Req 11.4.3, p. 277 LA
11.4.4	Correccion de vulnerabilidades explotables y debilidades encontradas en pruebas de penetración	Según la clasificación de riesgo del Req 6.3.1; prueba de penetración repetida para verificar correcciones	NO	NO	NO	NO	No tiene calendario fijo propio. Los hallazgos se corrigen segun el riesgo y el prueba de penetración se repite para verificar las correcciones.	PCI DSS v4.0.1, Req 11.4.4, p. 278 LA
11.4.5	Prueba de controles de segmentacion si se usa segmentacion	al menos una vez cada 12 meses (“anualmente”) y tras cambios en controles o métodos de segmentación	NO	SI	NO	NO	Solo aplica si la entidad usa segmentacion para aislar el CDE. El prueba confirma que los controles son operativos, efectivos y aislan el CDE de sistemas fuera del alcance.	PCI DSS v4.0.1, Req 11.4.5, p. 279 LA
11.4.6	Prueba de controles de segmentacion para proveedores de servicio	al menos una vez cada seis meses y tras cambios en controles o métodos de segmentación	NO	SI	NO	SI	Alta prioridad: los SP tienen frecuencia semestral para prueba de segmentación (vs. anual en 11.4.5). Solo aplica si usan segmentacion.	PCI DSS v4.0.1, Req 11.4.6, p. 280 LA
11.6.1	Mecanismo de deteccion de cambios y manipulacion en HTTP headers y scripts de paginas de pago	Al menos semanalmente o a la frecuencia definida en la TRA de la entidad	SI	NO	SI (si elige TRA)	NO	Alta prioridad: el requisito da dos opciones — semanal o TRA. Si elige TRA, la frecuencia debe estar justificada por el analisis de riesgo. El mecanismo evalua el contenido recibido por el browser del consumidor. Req activo a partir del 31 de marzo de 2025.	PCI DSS v4.0.1, Req 11.6.1, p. 287 LA
12.1.1	Revision de la politica general de seguridad de la informacion	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	La politica debe actualizarse cuando sea necesario para reflejar cambios en objetivos de negocio o riesgos. Distinguir entre la revision (anual) y la actualizacion (cuando sea necesario).	PCI DSS v4.0.1, Req 12.1.1, p. 290 LA
12.3.1	Proceso de análisis de riesgo específicos para requisitos con frecuencia “periódicamente”	Revisión al menos una vez cada 12 meses (“anualmente”); actualización según sea necesario	NO	NO	NO	NO	Meta-requisito: toda TRA debe incluir activos protegidos, amenazas, probabilidad e impacto, controles. La revision anual determina si la TRA sigue siendo valida. Alta prioridad: la TRA no es opconal; es obligatoria para todos los requisitos que dicen “periódicamente”.	PCI DSS v4.0.1, Req 12.3.1, p. 295 LA
12.3.2	TRA para cada control implementado mediante Enfoque Personalizado	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Solo aplica a entidades que usan el Enfoque Personalizado. La TRA para el CA es mas detallada que la de 12.3.1. El evaluador verifica tanto la TRA como la efectividad del control.	PCI DSS v4.0.1, Req 12.3.2, p. 297 LA
12.3.3	Revision de cipher suites y protocolos criptograficos en uso	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	La revision confirma que los algoritmos siguen siendo seguros y soportados. Alta prioridad para examen: esto complementa pero no reemplaza el requisito de usar criptografia fuerte de forma continua.	PCI DSS v4.0.1, Req 12.3.3, p. 298 LA
12.3.4	Revision de tecnologias de hardware y software en uso	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Verifica que las tecnologias siguen siendo soportadas por el vendor y cumplen los requisitos de seguridad de la entidad. Si no son soportadas, debe haber un plan de remediacion.	PCI DSS v4.0.1, Req 12.3.4, p. 299 LA
12.4.2	Revisiones de que el personal cumple las politicas y procedimientos operativos de seguridad (Solo SP)	al menos una vez cada tres meses (“trimestral”)	NO	NO	NO	SI	Alta prioridad: aplica SOLO a proveedores de servicio. Las revisiones las realiza personal distinto al que ejecuta la tarea. Cubre actividades BAU como revision de logs, reglas de NSC, gestion de cambios.	PCI DSS v4.0.1, Req 12.4.2, p. 301 LA
12.5.2	Confirmacion y documentacion de la determinación del alcance de PCI DSS	al menos una vez cada 12 meses (“anualmente”) y tras un cambio significativo	NO	SI	NO	NO	Alta prioridad: aplica a todos. La confirmacion anual la hace la entidad (no el evaluador). Incluye revision de todos los componentes del sistema, terceros, y flujos de datos de cuenta. Ver 12.5.2.1 para SP (semestral).	PCI DSS v4.0.1, Req 12.5.2, p. 304 LA
12.5.2.1	Confirmacion de determinación del alcance (Solo SP)	al menos una vez cada seis meses y tras un cambio significativo	NO	SI	NO	SI	Los SP tienen frecuencia semestral vs. anual para otros. Alta prioridad para examen: misma diferencia de sujeto/frecuencia que 11.4.6 vs. 11.4.5.	PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA
12.6.2	Revision del programa de concientizacion de seguridad	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	La revision asegura que el material esta actualizado respecto al panorama de amenazas actual. Distinguir entre revisar el programa (anual) y dar la capacitacion (tambien anual, Req 12.6.3).	PCI DSS v4.0.1, Req 12.6.2, p. 309 LA
12.6.3	Capacitacion en concientizacion de seguridad para todo el personal	Al ingresar y al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Doble disparador: al ingresar Y anualmente. El personal debe reconocer al menos anualmente que leyo y entendio la politica de seguridad. Alta prioridad: la falta de evidencia de reconocimiento es hallazgo tipico.	PCI DSS v4.0.1, Req 12.6.3, p. 310 LA
12.8.4	Monitoreo del estado de cumplimiento PCI DSS de los TPSP	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	La entidad debe monitorear que sus terceros criticos mantienen su cumplimiento PCI DSS. Puede hacerse mediante AOC del TPSP o presencia en lista de la marca de pago.	PCI DSS v4.0.1, Req 12.8.4, p. 318 LA
12.10.2	Revision y prueba del plan de respuesta a incidentes	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	La prueba debe incluir todos los elementos del Req 12.10.1. Alta prioridad: revisar (content update) Y probar (ejercicio) son dos actividades distintas, ambas anuales.	PCI DSS v4.0.1, Req 12.10.2, p. 327 LA
12.10.4	Capacitacion periodica de personal de respuesta a incidentes	Periódicamente (TRA)	NO	NO	SI	NO	La frecuencia la define la TRA (Req 12.10.4.1). Req activo a partir del 31 de marzo de 2025.	PCI DSS v4.0.1, Req 12.10.4, p. 329 LA; Req 12.10.4.1, p. 329 LA
A1.1.4	Prueba de controles de separacion logica entre entornos de clientes en SP multi-tenant	al menos una vez cada seis meses mediante prueba de penetración	NO	NO	NO	SI	Aplica SOLO a multi-tenant proveedores de servicio (Apendice A1). Es adicional a los pruebas de penetración de 11.4.6. El testing valida que un cliente no puede acceder al entorno de otro.	PCI DSS v4.0.1, Req A1.1.4, p. 337 LA
A3.1.1	Reporte al executive management y board sobre PCI DSS (DESV)	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Solo aplica a Designated Entities (Apendice A3, DESV). El reporte incluye iniciativas de cumplimiento y actividades de remediacion.	PCI DSS v4.0.1, Req A3.1.1, p. 347 LA
A3.1.4	Capacitacion en PCI DSS/seguridad de la informacion para personal con responsabilidades PCI DSS (DESV)	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Solo DESV. Distinto de 12.6.3 (concientizacion general para todo el personal). Esta capacitacion es especifica para roles con responsabilidades de cumplimiento PCI DSS.	PCI DSS v4.0.1, Req A3.1.4, p. 350 LA
A3.2.1	Confirmacion de determinación del alcance de PCI DSS (DESV)	al menos una vez cada tres meses (“trimestral”) y tras un cambio significativo	NO	SI	NO	NO	Solo DESV. Frecuencia trimestral vs. anual del Req 12.5.2 (todos) y semestral del 12.5.2.1 (SP). Alta prioridad: los DESV tienen el ciclo de validacion mas corto.	PCI DSS v4.0.1, Req A3.2.1, p. 351 LA
A3.2.5	Descubrimiento de datos (data discovery) de PAN en texto claro (DESV)	al menos una vez cada tres meses (“trimestral”) y tras cambios significativos en el CDE o los procesos	NO	SI	NO	NO	Solo DESV. Localiza todas las fuentes de PAN en texto claro. Alta prioridad: el examen puede preguntar sobre la diferencia entre data discovery (proactivo) y la eliminacion de datos (Req 3.2.1).	PCI DSS v4.0.1, Req A3.2.5, p. 357 LA
A3.2.5.1	Confirmacion de efectividad de metodos de data discovery (DESV)	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Solo DESV. Complementa A3.2.5: no basta con hacer el descubrimiento; hay que verificar que los metodos funcionan correctamente.	PCI DSS v4.0.1, Req A3.2.5.1, p. 358 LA
A3.3.2	Revision de tecnologias de hardware y software (DESV)	al menos una vez cada 12 meses (“anualmente”)	NO	NO	NO	NO	Solo DESV. Similar a 12.3.4 pero en el contexto de DESV, con requisitos de documentacion adicionales.	PCI DSS v4.0.1, Req A3.3.2, p. 364 LA
A3.3.3	Revision de que las actividades BAU se estan realizando (DESV)	al menos una vez cada tres meses (“trimestral”)	NO	NO	NO	NO	Solo DESV. El revisor es personal del programa de cumplimiento PCI DSS (identificado en A3.1.3), no el responsable de ejecutar la tarea. Cubre: revision de logs diarios, revisiones de reglas de NSC, cambios, acceso, etc.	PCI DSS v4.0.1, Req A3.3.3, p. 365 LA
A3.4.1	Revision de cuentas de usuario y privilegios de acceso a componentes del sistema dentro del alcance (DESV)	al menos una vez cada seis meses	NO	NO	NO	NO	Solo DESV. Similar a 7.2.4 pero especificamente para componentes dentro del alcance. Distinguir: 7.2.4 es para todos; A3.4.1 tiene requisitos adicionales para DESV.	PCI DSS v4.0.1, Req A3.4.1, p. 366 LA

Errores comunes del examen relacionados con periodicidad

“Periodic” no significa “anual”. La frecuencia de las actividades “periódicamente” la define la entidad mediante TRA. Una revision semestral o trimestral tambien es valida si esta justificada.
“Every 90 days” y “every three months” son equivalentes. El PDF los define asi en la seccion de definiciones (p. 25 LA). Los distractores suelen usar uno cuando el requisito usa el otro.
Cambio significativo no reemplaza al calendario. Las actividades disparadas por cambio significativo se realizan ADEMAS de las periodicas, no en lugar de ellas. Ej: los escaneos de vulnerabilidad trimestrales mas escaneos post-cambio son dos obligaciones independientes.
Los SP tienen frecuencias mas cortas en varios requisitos clave:
- Confirmación de alcance: semestral (12.5.2.1) vs. anual (12.5.2)
- Prueba de segmentación: semestral (11.4.6) vs. anual (11.4.5)
- Revisiones operativas: trimestral (12.4.2) — sin equivalente para comerciantes
La ausencia de TRA es incumplimiento en si misma. Si el requisito dice “periódicamente”, la entidad DEBE tener una TRA documentada que justifique la frecuencia elegida. No basta con hacer la actividad.
La revision del plan de IR (12.10.2) requiere tanto revision de contenido como prueba del plan. Son dos actividades distintas, ambas anuales.

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-26 LA.
- Sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21 LA.
- Requirements 1.2.7, 2.2.1, 3.2.1, 5.2.3, 5.3.2.1, 6.2.2, 6.2.3, 6.4.1, 6.5.2, 7.2.4, 7.2.5.1, 8.2.5, 8.2.6, 8.3.5, 8.3.9, 8.6.3, 9.3.1.1, 9.4.1.2, 9.4.5.1, 9.5.1.2, 9.5.1.2.1, 10.4.1, 10.4.2, 10.4.2.1, 10.5.1, 10.7.1, 10.7.2, 10.7.3, 11.2.1, 11.3.1, 11.3.1.1, 11.3.1.2, 11.3.1.3, 11.3.2, 11.3.2.1, 11.4.1, 11.4.2, 11.4.3, 11.4.4, 11.4.5, 11.4.6, 11.6.1, 12.1.1, 12.3.1, 12.3.2, 12.3.3, 12.3.4, 12.4.2, 12.5.2, 12.5.2.1, 12.6.2, 12.6.3, 12.8.4, 12.10.2, 12.10.4, 12.10.4.1.
- Appendix A1: Req A1.1.4, p. 337 LA.
- Appendix A3 (DESV): Req A3.1.1, A3.1.4, A3.2.1, A3.2.5, A3.2.5.1, A3.3.2, A3.3.3, A3.4.1, p. 347-366 LA.
Links de referencia PCI SSC: docs/links-pci.txt.