Periodicidad
Periodicidad, BAU y Significant Change
Periodicidad, BAU y Significant Change — 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.
- Significant Change: SI si el requisito también se dispara tras un significant change, independientemente del calendario.
- TRA: SI si la frecuencia no está fija en el estándar y la define la entidad mediante targeted risk analysis (Req 12.3.1).
- Solo SP: SI si el requisito aplica exclusivamente a service providers.
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).
Definiciones clave de marcos temporales (PCI DSS v4.0.1, p. 25)
| Término en el PDF | Equivalente normalizado |
|---|---|
| Daily | Diario — todos los días del año, incluyendo fines de semana |
| Weekly | Semanal — al menos una vez cada 7 días |
| Every 30 days | Mensual — al menos cada 30-31 días |
| Every three months / “quarterly” | Trimestral — al menos cada 90-92 días |
| Every six months | Semestral — al menos cada 180-184 días |
| Every 12 months / “annually” | Anual — al menos cada 365/366 días |
| Periodically | Definido por la entidad, soportado por TRA (Req 12.3.1) |
| Immediately | Sin demora, en tiempo real o casi real |
| Promptly | 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.mdBloque 1.
Definición de Significant Change (PCI DSS v4.0.1, p. 25-26)
Constituye significant change, 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 account data.
- Cambios en el límite del CDE o en el scope 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/service providers que soportan el CDE o cumplen requisitos PCI DSS en nombre de la entidad.
Lo que constituye un significant change 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 | Sig. Change | TRA | Solo SP | Notas para examen | Fuente |
|---|---|---|---|---|---|---|---|---|
| 1.2.7 | Revision de configuraciones de NSC | at least once every six months | 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 |
| 2.2.1 | Aplicacion de configuration standards a nuevos sistemas | before or immediately after a system component is connected to a production environment | SI | SI | NO | NO | Trigger: conexion de nuevo sistema a produccion. No es periodico; es event-driven. Alta prioridad: los distractores sugieren que aplica solo en produccion establecida. | PCI DSS v4.0.1, Req 2.2.1, p. 41 |
| 3.2.1 | Verificacion de que account data no excede retencion definida y es eliminada de forma segura | at least once every three months | 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 |
| 5.2.3 | Evaluacion periodica de componentes del sistema no en riesgo de malware | Periodically (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 |
| 5.3.2.1 | Frecuencia de escaneos periodicos de malware | Periodically (TRA) | SI | NO | SI | NO | Aplica solo si la entidad usa periodic scans (en lugar de continuous monitoring). 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 |
| 6.2.2 | Capacitacion en codificacion segura para desarrolladores de software a medida | at least once every 12 months | NO | NO | NO | NO | Aplica a personal que desarrolla bespoke and custom software. 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 |
| 6.2.3 | Revision de codigo antes de liberarse a produccion | prior to being released into production or to customers | SI | NO | NO | NO | Trigger: pre-release. No es periodico; es event-driven. Se requiere para todo bespoke and custom software. El assessor busca evidencia de que toda liberacion paso por revision. | PCI DSS v4.0.1, Req 6.2.3, p. 138 |
| 6.2.3.1 | Revisiones manuales de codigo: revisadas y aprobadas por individuo distinto al autor | prior to release to production | 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 |
| 6.4.1 | Evaluacion de seguridad de aplicaciones web publicas O solucion automatizada continua (WAF/AST) | Opcion A: at least once every 12 months and after significant changes / Opcion B: continua (automated, real time) | 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 sig change, 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 |
| 6.5.2 | Confirmacion de cumplimiento de todos los requisitos PCI DSS aplicables tras significant change | Upon completion of a significant change | SI | SI | NO | NO | Trigger: cierre de un significant change. El cambio debe capturarse en la confirmacion anual de scope (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 |
| 7.2.4 | Revision de todas las cuentas de usuario y privilegios de acceso (incluyendo terceros/vendors) | at least once every six months | 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 |
| 7.2.5.1 | Revision de cuentas de aplicacion y sistema y sus privilegios | Periodically (TRA) | SI | NO | SI | NO | Frecuencia definida por TRA. Distinto de 7.2.4 (cuentas de usuario, semestral fijo). Los assessors verifican tanto la TRA como la evidencia de revision. | PCI DSS v4.0.1, Req 7.2.5.1, p. 169 |
| 8.2.5 | Revocacion inmediata de acceso de usuarios terminados | Immediately upon termination | SI | NO | NO | NO | Event-driven: terminacion del usuario. “Immediately” = 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 |
| 8.2.6 | Desactivacion de cuentas inactivas dentro de 90 dias | Within 90 days of inactivity | SI | NO | NO | NO | Trigger: 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 |
| 8.3.5 | Cambio de contrasena/passphrase en primer uso | Immediately after first use | SI | NO | NO | NO | Trigger: 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 |
| 8.3.9 | Cambio de contrasena/passphrase al menos cada 90 dias (si es el unico factor de autenticacion) | at least once every 90 days OR dynamic analysis of security posture | 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 |
| 8.6.3 | Cambio periodico de contrasenas de cuentas de aplicacion y sistema; proteccion contra mal uso | Periodically (TRA) and upon suspicion or confirmation of compromise | SI | NO | SI | NO | Doble trigger: 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 |
| 9.3.1.1 | Revocacion inmediata de acceso fisico a areas sensibles al terminar relacion | Immediately upon termination | 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 |
| 9.4.1.2 | Revision de seguridad de la ubicacion de backup de medios fisicos offline con CHD | at least once every 12 months | 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 |
| 9.4.5.1 | Inventario de medios electronicos con CHD | at least once every 12 months | NO | NO | NO | NO | Inventario fisico de medios. El assessor 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 |
| 9.5.1.2 | Inspeccion periodica de superficies de dispositivos POI | Periodically | 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 |
| 9.5.1.2.1 | Frecuencia e tipo de inspecciones de dispositivos POI | Periodically (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 |
| 10.4.1 | Revision diaria de logs de eventos de seguridad, alertas IDS/IPS, sistemas criticos y sistemas criptograficos criticos | at least once daily | SI | NO | NO | NO | Alta prioridad: “daily” = 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 |
| 10.4.2 | Revision periodica de logs de otros componentes del sistema (no cubiertos por 10.4.1) | Periodically (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; Req 10.4.2.1, p. 249 |
| 10.5.1 | Retencion de historial de audit logs al menos 12 meses; 3 meses inmediatamente disponibles | Retain at least 12 months; most recent 3 months immediately available | SI | NO | NO | NO | Alta prioridad: dos requisitos en uno — retencion total (12 meses) y acceso rapido (3 meses en linea/inmediato). “Immediately available” significa sin necesidad de procesos de restauracion lentos. | PCI DSS v4.0.1, Req 10.5.1, p. 251 |
| 10.7.1 | Deteccion y respuesta a fallas de sistemas de control de seguridad criticos (SP only hasta marzo 2025) | Promptly upon detection of failure | SI | NO | NO | SI | Aplica SOLO a service providers 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 |
| 10.7.2 | Deteccion y respuesta a fallas de sistemas de control de seguridad criticos (todos desde marzo 2025) | Promptly upon detection of failure | SI | NO | NO | NO | Incluye NSC, IDS/IPS, change-detection mechanisms, anti-malware, audit log, segmentation controls, audit log review solutions, automated security testing tools. Activo a partir del 31 de marzo de 2025. | PCI DSS v4.0.1, Req 10.7.2, p. 256 |
| 10.7.3 | Respuesta a fallas de sistemas de control de seguridad criticos | Promptly upon detection | 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 |
| 11.2.1 | Deteccion y testing de puntos de acceso inalambrico no autorizados | at least once every three months | 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 |
| 11.3.1 | Escaneos de vulnerabilidades internas | at least once every three months | 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 |
| 11.3.1.1 | Tratamiento de vulnerabilidades de menor riesgo encontradas en escaneos internos | Periodically (TRA) — based on risk | 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 |
| 11.3.1.2 | Escaneos internos autenticados | at least once every three months | NO | NO | NO | NO | Es el metodo obligatorio para realizar los escaneos internos de 11.3.1 (best practice 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 |
| 11.3.1.3 | Escaneos de vulnerabilidades internas despues de significant change | After any significant change | 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 |
| 11.3.2 | Escaneos de vulnerabilidades externas (ASV) | at least once every three months | 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 “passing scan”. | PCI DSS v4.0.1, Req 11.3.2, p. 270 |
| 11.3.2.1 | Escaneos de vulnerabilidades externas despues de significant change | After any significant change | 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 |
| 11.4.1 | Metodologia de penetration testing definida, documentada e implementada | Per methodology; results/remediation retained at least 12 months | NO | NO | NO | NO | No es la ejecucion del pen test. Define cobertura, testing interno/externo, 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 |
| 11.4.2 | Prueba de penetracion interna | at least once every 12 months and after any significant infrastructure or application upgrade or change | 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 |
| 11.4.3 | Prueba de penetracion externa | at least once every 12 months and after any significant infrastructure or application upgrade or change | 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 |
| 11.4.4 | Correccion de vulnerabilidades explotables y debilidades encontradas en penetration testing | According to risk ranking per Req 6.3.1; penetration testing repeated to verify corrections | NO | NO | NO | NO | No tiene calendario fijo propio. Los hallazgos se corrigen segun el riesgo y el pen test se repite para verificar las correcciones. | PCI DSS v4.0.1, Req 11.4.4, p. 278 |
| 11.4.5 | Testing de controles de segmentacion si se usa segmentacion | at least once every 12 months and after any changes to segmentation controls/methods | NO | SI | NO | NO | Solo aplica si la entidad usa segmentacion para aislar el CDE. El testing confirma que los controles son operativos, efectivos y aislan el CDE de sistemas out of scope. | PCI DSS v4.0.1, Req 11.4.5, p. 279 |
| 11.4.6 | Testing de controles de segmentacion para service providers | at least once every six months and after any changes to segmentation controls/methods | NO | SI | NO | SI | Alta prioridad: los SP tienen frecuencia semestral para segmentation testing (vs. anual en 11.4.5). Solo aplica si usan segmentacion. | PCI DSS v4.0.1, Req 11.4.6, p. 280 |
| 11.6.1 | Mecanismo de deteccion de cambios y manipulacion en HTTP headers y scripts de paginas de pago | At least weekly OR at the frequency defined in entity’s TRA | 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 |
| 12.1.1 | Revision de la politica general de seguridad de la informacion | at least once every 12 months | 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 |
| 12.3.1 | Proceso de targeted risk analysis para requisitos con frecuencia “periodically” | Review at least once every 12 months; perform updates as needed | 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 “periodically”. | PCI DSS v4.0.1, Req 12.3.1, p. 295 |
| 12.3.2 | TRA para cada control implementado mediante Customized Approach | at least once every 12 months | NO | NO | NO | NO | Solo aplica a entidades que usan el Customized Approach. La TRA para el CA es mas detallada que la de 12.3.1. El assessor verifica tanto la TRA como la efectividad del control. | PCI DSS v4.0.1, Req 12.3.2, p. 297 |
| 12.3.3 | Revision de cipher suites y protocolos criptograficos en uso | at least once every 12 months | 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 |
| 12.3.4 | Revision de tecnologias de hardware y software en uso | at least once every 12 months | 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 |
| 12.4.2 | Revisiones de que el personal cumple las politicas y procedimientos operativos de seguridad (SP only) | at least once every three months | NO | NO | NO | SI | Alta prioridad: aplica SOLO a service providers. Las revisiones las realiza personal distinto al que ejecuta la tarea. Cubre BAU activities como revision de logs, reglas de NSC, gestion de cambios. | PCI DSS v4.0.1, Req 12.4.2, p. 301 |
| 12.5.2 | Confirmacion y documentacion del scope de PCI DSS | at least once every 12 months and upon significant change | NO | SI | NO | NO | Alta prioridad: aplica a todos. La confirmacion anual la hace la entidad (no el assessor). 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 |
| 12.5.2.1 | Confirmacion de scope (SP only) | at least once every six months and upon significant change | 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 |
| 12.6.2 | Revision del programa de concientizacion de seguridad | at least once every 12 months | 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 |
| 12.6.3 | Capacitacion en concientizacion de seguridad para todo el personal | Upon hire and at least once every 12 months | NO | NO | NO | NO | Doble trigger: 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 |
| 12.8.4 | Monitoreo del estado de cumplimiento PCI DSS de los TPSP | at least once every 12 months | 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 |
| 12.10.2 | Revision y prueba del plan de respuesta a incidentes | at least once every 12 months | 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 |
| 12.10.4 | Capacitacion periodica de personal de respuesta a incidentes | Periodically (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; Req 12.10.4.1, p. 329 |
| A1.1.4 | Testing de controles de separacion logica entre entornos de clientes en SP multi-tenant | at least once every six months via penetration testing | NO | NO | NO | SI | Aplica SOLO a multi-tenant service providers (Apendice A1). Es adicional a los pen tests 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 |
| A3.1.1 | Reporte al executive management y board sobre PCI DSS (DESV) | at least once every 12 months | 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 |
| A3.1.4 | Capacitacion en PCI DSS/seguridad de la informacion para personal con responsabilidades PCI DSS (DESV) | at least once every 12 months | 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 |
| A3.2.1 | Confirmacion de scope de PCI DSS (DESV) | at least once every three months and upon significant change | 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 |
| A3.2.5 | Descubrimiento de datos (data discovery) de PAN en texto claro (DESV) | at least once every three months and upon significant changes to CDE or processes | 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 |
| A3.2.5.1 | Confirmacion de efectividad de metodos de data discovery (DESV) | at least once every 12 months | 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 |
| A3.3.2 | Revision de tecnologias de hardware y software (DESV) | at least once every 12 months | 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 |
| A3.3.3 | Revision de que las actividades BAU se estan realizando (DESV) | at least once every three months | 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 |
| A3.4.1 | Revision de cuentas de usuario y privilegios de acceso a componentes del sistema en scope (DESV) | at least once every six months | NO | NO | NO | NO | Solo DESV. Similar a 7.2.4 pero especificamente para componentes en scope. 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 |
Errores comunes del examen relacionados con periodicidad
-
“Periodic” no significa “anual”. La frecuencia de las actividades “periodically” 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). Los distractores suelen usar uno cuando el requisito usa el otro.
-
Significant change no reemplaza al calendario. Las actividades triggered by significant change 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:
- Scope confirmation: semestral (12.5.2.1) vs. anual (12.5.2)
- Segmentation testing: semestral (11.4.6) vs. anual (11.4.5)
- Operational reviews: trimestral (12.4.2) — sin equivalente para merchants
-
La ausencia de TRA es incumplimiento en si misma. Si el requisito dice “periodically”, 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: 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-26.
- Sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21.
- 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.
- 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.
- Links de referencia PCI SSC:
docs/links-pci.txt.