Temas
Temas de alto riesgo
Temas de alto riesgo para el examen ISA — PCI DSS v4.0.1
Este archivo cubre los temas con mayor probabilidad de error en el examen ISA. Para cada tema se presenta la regla exacta del estándar, las trampas más frecuentes y lo que un assessor debe buscar como evidencia.
Complementa a pci-isa-exam-guide.md (mindset y estrategia), periodicity-bau-significant-change.md (tabla de periodicidades) y recurring-activities-by-timeframe.md (vista por marco temporal).
Tema 1. Determinacion del alcance: que entra y que queda fuera del alcance
Regla del estándar
Los requisitos de PCI DSS se aplican a:
“El entorno de datos de tarjetahabiente (CDE), que se compone de: – Componentes del sistema, personas y procesos que almacenan, procesan o transmiten datos de tarjetahabiente y/o datos de autenticacion sensibles, y, – Componentes del sistema que aunque no almacenan, procesan o transmiten CHD/SAD pero que tienen una conectividad sin restricciones con componentes del sistema que almacenan, procesan o transmiten CHD/SAD. Y Componentes del sistema, personas y procesos que podrian afectar la seguridad de datos de tarjetahabiente y/o datos de autenticacion sensibles.” (PCI DSS v4.0.1, seccion “Alcance de los Requisitos de PCI DSS”, p. 9 LA)
Las tres categorias de componentes del sistema dentro del alcance
| Categoría | Definición | Ejemplo |
|---|---|---|
| SPT | Almacena, procesa o transmite CHD/SAD | Servidor de pagos, terminal POS |
| Conectado a | Conectividad sin restricciones hacia componentes SPT | Servidor de autenticación sin segmentación |
| Impacto en seguridad | Podría impactar la seguridad del CDE si se compromete | Servidor DNS, servidor de logging, servidor de redirección e-commerce |
Alta prioridad para examen: la categoría “impacto en seguridad” es la que más se olvida. Un servidor que no toca CHD pero cuya compromisión permitiría acceder al CDE está dentro del alcance.
Datos del titular de la tarjeta vs datos de autenticacion sensibles
Datos del titular de la tarjeta (CHD): PAN, nombre del titular, fecha de vencimiento, codigo de servicio.
- El PAN es el elemento definitorio. Los otros tres solo son CHD si están presentes con el PAN.
- Almacenamiento del PAN: permitido con protección (Req 3.5).
Datos de autenticacion sensibles (SAD): datos de pista completos (o equivalente en chip), código de verificación de tarjeta (CVV/CVC/CID), PIN/bloques PIN.
- SAD nunca puede almacenarse después de la autorización de la transacción, ni siquiera cifrado.
- Esta regla aplica incluso si el entorno no almacena PAN. (PCI DSS v4.0.1, Tabla 2 y Tabla 3, p. 4-6 LA)
Confirmación anual de alcance
La entidad debe confirmar la exactitud de su alcance al menos una vez cada 12 meses y ante cambio significativo (Req 12.5.2). Esta actividad la realiza la entidad; no reemplaza la confirmación de alcance que hace el assessor durante la evaluación. (PCI DSS v4.0.1, sección “Confirmación Anual del Alcance PCI DSS”, p. 12 LA)
Errores comunes de examen
- Error: asumir que si el sistema no toca datos de tarjeta, queda fuera del alcance. Los sistemas con conectividad sin restricciones o impacto en seguridad también están dentro del alcance.
- Error: tratar CHD y SAD como sinónimos. Las reglas de almacenamiento son distintas.
- Error: creer que la confirmación de alcance es tarea del assessor, no de la entidad.
Tema 2. Segmentación: no es requisito pero tiene consecuencias si se usa
Regla del estándar
“La segmentación (o aislamiento) del CDE del resto de la red de una entidad no es un requisito de PCI DSS. Sin embargo, se recomienda fuertemente.” (PCI DSS v4.0.1, seccion “Segmentacion”, p. 12 LA)
Sin segmentación adecuada, toda la red está dentro del alcance.
Para que un componente quede fuera del alcance, debe estar segmentado de modo que no pueda impactar la seguridad del CDE, incluso si ese componente fuera comprometido.
Pruebas de segmentación
Si la entidad usa segmentación para aislar el CDE, esta debe probarse:
| Requisito | Obligación | Frecuencia | Solo SP |
|---|---|---|---|
| 11.4.5 | Prueba de penetracion sobre controles de segmentación | Al menos una vez cada 12 meses y después de cualquier cambio en los controles de segmentación | No (si usan segmentación) |
| 11.4.6 | Prueba de penetracion sobre controles de segmentación | Al menos una vez cada seis meses y después de cualquier cambio | Sí (solo proveedores de servicio) |
La prueba de penetracion debe confirmar que los controles de segmentación son operativos, efectivos, y que aíslan el CDE de todos los sistemas fuera del alcance. (PCI DSS v4.0.1, Req 11.4.5, p. 279 LA; Req 11.4.6, p. 280 LA)
Errores comunes de examen
- Error: creer que el estándar exige segmentar. No es un requisito; es una recomendación.
- Error: creer que si no hay segmentación, no hay nada que probar en el Req 11.4.5. El requisito se activa solo si la entidad usa segmentación; si no la usa, no aplica.
- Error: confundir la frecuencia de SP (semestral, Req 11.4.6) con la de comerciantes (anual, Req 11.4.5).
Tema 3. BAU y gestion de cambios: relación y diferencias
Qué es BAU en PCI DSS
BAU (procesos habituales) son los procesos mediante los cuales la entidad integra los controles PCI DSS en la operación diaria, no solo en el momento de la evaluación. El objetivo es que el ambiente se mantenga en cumplimiento entre evaluaciones.
“Una entidad que implementa procesos de negocio tradicionales también conocidos como BAU, como parte de su estrategia global de seguridad, está tomando medidas para garantizar que los controles de seguridad que se han implementado para asegurar los datos y un entorno siguen siendo implementados correctamente y funcionando adecuadamente como curso normal de los negocios.” (PCI DSS v4.0.1, seccion “Mejores Practicas para la Implementacion PCI DSS en Procesos Habituales”, p. 19 LA)
Relación entre BAU y gestion de cambios
Los procesos de gestion de cambios son parte de BAU. Antes de completar un cambio, la entidad debe:
- Evaluar el impacto potencial en el alcance PCI DSS (¿el cambio trae nuevos sistemas al CDE?).
- Identificar los requisitos PCI DSS aplicables a los sistemas o redes afectadas.
- Actualizar el alcance PCI DSS e implementar controles de seguridad según corresponda.
- Actualizar la documentación para reflejar los cambios implementados. (PCI DSS v4.0.1, sección BAU, p. 19-20 LA)
Req 6.5.1: control de cambios para todos los componentes del sistema
Todo cambio en el ambiente de producción debe seguir procedimientos establecidos que incluyan, al menos:
- Razón y descripción del cambio.
- Documentación del impacto en seguridad.
- Aprobación documentada por partes autorizadas.
- Pruebas para verificar que el cambio no afecta adversamente la seguridad.
- Para software a medida y personalizado: pruebas de cumplimiento con Req 6.2.4 antes de desplegar en producción.
- Procedimientos para tratar fallas y retornar a un estado seguro. (PCI DSS v4.0.1, Req 6.5.1, p. 155 LA)
Req 6.5.2: confirmar PCI DSS tras cambio significativo
“Tras concluir un cambio significativo, se confirma que todos los requisitos PCI DSS aplicables estén implementados en todos los sistemas y redes nuevos o modificados, y se actualiza la documentación según corresponda.” (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA)
Procedimiento de prueba: el assessor examina documentación de cambios significativos, entrevista personal y observa los sistemas/redes afectados para verificar que la entidad confirmó que los requisitos PCI DSS aplicables estaban implementados en todos los sistemas o redes nuevos o cambiados.
Nota de aplicabilidad: estos cambios significativos también deben capturarse y reflejarse en la actividad anual de confirmación de alcance del Req 12.5.2.
Ejemplos de requisitos impactados: actualización de diagramas de red y flujos de datos, configuración de sistemas según estándares, protección con FIM/anti-malware/patches/logging, verificación de que no se almacena SAD, inclusión de nuevos sistemas en el proceso trimestral de escaneo de vulnerabilidades, escaneos de vulnerabilidades tras cambio (Req 11.3.1.3 y 11.3.2.1). (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA)
Lo que el assessor busca como evidencia
| Para BAU | Para gestion de cambios |
|---|---|
| Mecanismos de monitoreo continuo en operación (IDS/IPS, FIM, anti-malware, logs de acceso) | Tickets de control de cambios con: descripción, impacto en seguridad, aprobación, resultados de pruebas |
| Registros de revisiones periódicas (reportes de escaneo, revisiones de logs, revisiones de reglas) | Documentación de evaluación de impacto en el alcance PCI DSS antes del cambio |
| Evidencia de respuesta a fallas de controles | Escaneos posteriores al cambio (Req 11.3.1.3, 11.3.2.1) y confirmación de requisitos (Req 6.5.2) |
| Política que asigna responsabilidad de cumplimiento PCI DSS | Diagramas de red actualizados que reflejan los cambios |
Errores comunes de examen
- Error: confundir “política de gestion de cambios documentada” con “evidencia de que el proceso opera”. El assessor necesita ambas.
- Error: olvidar que Req 6.5.2 exige confirmación activa de PCI DSS tras cambio. No basta con el ticket de cambio.
- Error: creer que BAU solo aplica a los requisitos marcados como tal en el estándar. El estándar indica que la entidad debe adoptar BAU adicionales según su entorno.
Tema 4. Req 6.4.1 y 6.4.2: protección de aplicaciones web públicas
Contexto: transición de 6.4.1 a 6.4.2
Este es uno de los temas de mayor confusión por la transición de requisitos:
- Req 6.4.1 fue el requisito vigente hasta el 31 de marzo de 2025. Ofrecía dos opciones: (a) revisión anual por especialista en seguridad de aplicaciones, o (b) solución técnica automatizada que detecta y previene ataques de forma continua. (PCI DSS v4.0.1, Req 6.4.1, p. 150 LA)
- Req 6.4.2 reemplaza a 6.4.1 desde el 31 de marzo de 2025. Exige únicamente la opción (b): solución automatizada que detecta y previene ataques de forma continua (ya no se puede elegir entre revisión anual o WAF). (PCI DSS v4.0.1, Req 6.4.2, p. 151-152 LA)
Nota de aplicabilidad de Req 6.4.1: “Este requisito será sustituido por el Requisito 6.4.2 después del 31 de marzo de 2025, cuando el Requisito 6.4.2 entre en vigor.” (PCI DSS v4.0.1, Req 6.4.1, p. 151 LA)
Nota de aplicabilidad de Req 6.4.2: “Este nuevo requisito reemplazará al Requisito 6.4.1 una vez que se alcance su fecha de entrada en vigor. Este requisito es una práctica recomendada hasta el 31 de marzo de 2025, fecha a partir de la cual será obligatorio y deberá tenerse en cuenta en su totalidad durante una evaluación PCI DSS.” (PCI DSS v4.0.1, Req 6.4.2, p. 152 LA)
Req 6.4.1 (vigente hasta 31/03/2025): dos opciones
Opción A — Revisión manual o automatizada:
- Al menos una vez cada 12 meses y después de cambios significativos.
- Por una entidad especializada en seguridad de aplicaciones.
- Incluye, como mínimo, todos los ataques comunes del Req 6.2.4.
- Todas las vulnerabilidades son clasificadas conforme al Req 6.3.1.
- Todas las vulnerabilidades son corregidas.
- La aplicación es re-evaluada después de las correcciones.
Opción B — Solución técnica automatizada:
- Instalada frente a las aplicaciones web públicas.
- Activamente en ejecución y actualizada.
- Genera registros de auditoría.
- Configurada para bloquear ataques o generar alertas que son investigadas de forma inmediata.
Ejemplo: WAF (Web Application Firewall) instalado frente a aplicaciones web públicas. (PCI DSS v4.0.1, Req 6.4.1, p. 150-151 LA)
Req 6.4.2 (requerido desde 01/04/2025): solo opción B
El requisito exige exclusivamente la solución automatizada que detecta y previene ataques de forma continua. No existe opción de revisión anual por especialista como alternativa. Los elementos son los mismos que la Opción B del Req 6.4.1.
Esta evaluación NO es lo mismo que los análisis de 11.3.1/11.3.2
Nota de aplicabilidad: esta evaluación no es la misma que los análisis de vulnerabilidades realizados para los Requisitos 11.3.1 y 11.3.2. (PCI DSS v4.0.1, Req 6.4.1, p. 151 LA)
Lo que el assessor busca como evidencia
Para Req 6.4.2 (post-31/03/2025):
- Configuración del sistema (WAF u otra solución automatizada): instalada frente a aplicaciones web, activa, actualizada.
- Registros de auditoría de la solución.
- Entrevista con personal responsable.
Errores comunes de examen
- Error: creer que después del 31/03/2025 aún se puede elegir entre revisión anual por especialista o WAF. Desde esa fecha solo es válida la solución automatizada continua (Req 6.4.2).
- Error: confundir la evaluación de 6.4.1/6.4.2 con los análisis de vulnerabilidades del Req 11.3.1/11.3.2. Son controles distintos.
- Error: no verificar que la solución automatizada genera registros de auditoría y está activamente actualizada.
Tema 5. Req 11.x: pruebas de sistemas y redes
Mapa de Req 11.x
| Req | Control | Frecuencia | Solo SP |
|---|---|---|---|
| 11.2.1 | Escaneo de puntos de acceso inalámbrico no autorizados | Al menos una vez cada tres meses | No |
| 11.3.1 | Escaneo interno de vulnerabilidades | Al menos una vez cada tres meses; vulnerabilidades altas/críticas resueltas; reescaneo hasta confirmar | No |
| 11.3.1.1 | Vulnerabilidades de menor riesgo (no altas/críticas) | Según TRA (Req 12.3.1); reescaneo según necesidad. Requerido desde 31/03/2025 | No |
| 11.3.1.2 | Escaneo autenticado interno | Al menos una vez cada tres meses. Requerido desde 31/03/2025 | No |
| 11.3.1.3 | Escaneo interno tras cambio significativo | Tras cambio significativo; vulnerabilidades altas/críticas resueltas | No |
| 11.3.2 | Escaneo externo de vulnerabilidades por ASV | Al menos una vez cada tres meses; analisis aprobado | No |
| 11.3.2.1 | Escaneo externo tras cambio significativo | Tras cambio significativo; analisis aprobado | No |
| 11.4.1 | Metodología de pruebas de penetracion definida y documentada | No es periódico; es un requisito de tener la metodología activa | No |
| 11.4.2 | Prueba de penetracion interna | Al menos una vez cada 12 meses y tras cambio significativo | No |
| 11.4.3 | Prueba de penetracion externa | Al menos una vez cada 12 meses y tras cambio significativo | No |
| 11.4.4 | Remediación de hallazgos de la prueba de penetracion | Según clasificacion de riesgo del Req 6.3.1; repeticion de pruebas para confirmar | No |
| 11.4.5 | Prueba de penetracion sobre controles de segmentación | Al menos una vez cada 12 meses y tras cambio en segmentación | No (si usan segmentación) |
| 11.4.6 | Prueba de penetracion sobre controles de segmentación | Al menos una vez cada seis meses y tras cambio | Solo SP |
| 11.4.7 | Soporte a clientes para pruebas de penetracion externas | Sin frecuencia fija (control de capacidad) | Solo SP multiusuario |
| 11.5.1 | IDS/IPS: monitoreo continuo en perímetro y puntos críticos del CDE | Continuo | No |
| 11.5.1.1 | Detección de canales de comunicación encubiertos de malware | Continuo. Requerido desde 31/03/2025 | Solo SP |
| 11.5.2 | FIM/deteccion de cambios: comparación de archivos críticos | Al menos una vez por semana | No |
| 11.6.1 | Detección de cambios en páginas de pago (deteccion de manipulaciones) | Al menos una vez por semana o según TRA (Req 12.3.1) | No (aplica a e-commerce) |
Fuentes: PCI DSS v4.0.1, Req 11.2.1 (p. 261 LA), 11.3.1 (p. 266 LA), 11.3.1.1 (p. 268 LA), 11.3.1.2 (p. 269 LA), 11.3.1.3 (p. 270 LA), 11.3.2 (p. 271 LA), 11.3.2.1 (p. 272 LA), 11.4.1-11.4.7 (p. 274-282 LA), 11.5.1 (p. 283 LA), 11.5.1.1 (p. 284 LA), 11.5.2 (p. 286 LA), 11.6.1 (p. 288 LA).
Req 11.3.1 a fondo: escaneo interno trimestral
El requisito exige:
- Ejecutar el escaneo al menos una vez cada tres meses.
- Resolver todas las vulnerabilidades de alto riesgo o críticas (según la clasificacion de riesgo definido en Req 6.3.1).
- Ejecutar reescaneo para confirmar que las vulnerabilidades altas y criticas quedaron resueltas.
- Mantener la herramienta de escaneo actualizada con la información de vulnerabilidades más reciente.
- Ejecutado por personal calificado con independencia organizacional del evaluador.
Nota: no se exige QSA ni ASV para el escaneo interno. (PCI DSS v4.0.1, Req 11.3.1, p. 266 LA)
Req 11.3.1.1: vulnerabilidades de menor riesgo (nuevo, desde 31/03/2025)
Las vulnerabilidades no clasificadas como altas o criticas deben gestionarse según el riesgo definido en la TRA de la entidad (Req 12.3.1). La TRA debe incluir como mínimo: identificación de activos protegidos, amenazas y factores de probabilidad/impacto. (PCI DSS v4.0.1, Req 11.3.1.1, p. 268 LA)
Req 11.4.1: metodología de pruebas de penetracion
La entidad debe definir, documentar e implementar una metodología que incluya, como mínimo:
- Enfoques de pruebas de penetracion aceptados por la industria.
- Cobertura del perímetro completo del CDE y sistemas críticos.
- Pruebas desde adentro y desde afuera de la red.
- Validación de controles de segmentación y reducción de alcance.
- Pruebas de penetracion de capa de aplicación (vulnerabilidades del Req 6.2.4, como mínimo).
- Pruebas de penetracion de capa de red (todos los componentes que soporten funciones de red y sistemas operativos).
- Revisión y consideración de amenazas y vulnerabilidades de los últimos 12 meses.
- Enfoque documentado para evaluar y abordar el riesgo de vulnerabilidades encontradas.
- Retención de resultados de pruebas de penetracion y actividades de remediación durante al menos 12 meses. (PCI DSS v4.0.1, Req 11.4.1, p. 274-275 LA)
Req 11.4.2 y 11.4.3: prueba de penetracion interna y externa
Ambos deben ejecutarse al menos una vez cada 12 meses y después de cualquier actualización o cambio significativo de infraestructura o aplicación. El evaluador (interno o externo calificado) debe tener independencia organizacional respecto del componente que prueba; no se exige que sea QSA ni ASV.
Evidencia requerida: alcance del trabajo + resultados de la prueba de penetracion más reciente. (PCI DSS v4.0.1, Req 11.4.2, p. 276 LA; Req 11.4.3, p. 277 LA)
Req 11.5.2: FIM semanal
El mecanismo de deteccion de cambios (por ejemplo, FIM) debe:
- Alertar al personal ante modificación no autorizada (incluyendo cambios, adiciones y eliminaciones) de archivos críticos.
- Realizar comparaciones de archivos críticos al menos una vez por semana.
Los archivos críticos son aquellos que no cambian regularmente pero cuya modificación podría indicar compromiso del sistema. Los productos de FIM generalmente incluyen una lista preconfigurada de archivos críticos del sistema operativo; la entidad debe definir archivos críticos adicionales de aplicaciones propias. (PCI DSS v4.0.1, Req 11.5.2, p. 286 LA)
Req 11.6.1: deteccion de manipulaciones en páginas de pago
Aplica a entidades con páginas de pago en e-commerce. El mecanismo debe:
- Alertar ante modificación no autorizada de los encabezados HTTP de seguridad y el contenido de scripts de las páginas de pago según lo recibe el navegador del consumidor.
- Estar configurado para evaluar los encabezados HTTP y las páginas de pago.
- Funcionar al menos una vez por semana O a la frecuencia definida en la TRA de la entidad (Req 12.3.1).
(PCI DSS v4.0.1, Req 11.6.1, p. 288 LA)
Diferencias críticas en el bloque 11.x
| Diferencia | Detalle |
|---|---|
| Escaneo interno vs. escaneo externo (ASV) | El externo exige ASV certificado; el interno puede ser personal interno calificado |
| Escaneo trimestral vs. tras cambio significativo | Req 11.3.1 = trimestral (calendario); Req 11.3.1.3 = basado en eventos (tras cambio) |
| Prueba de penetracion anual vs. semestral de segmentación | 11.4.5 = anual (todos); 11.4.6 = semestral (solo SP) |
| FIM vs. deteccion de manipulaciones de pago | 11.5.2 = archivos críticos del sistema (semanal fijo); 11.6.1 = páginas de pago (semanal o TRA) |
Lo que el assessor busca como evidencia en 11.x
| Req | Evidencia principal |
|---|---|
| 11.3.1 | Reportes de escaneo trimestrales de los últimos 12 meses; reportes de reescaneo confirmando resolución de vulnerabilidades altas/críticas |
| 11.3.2 | Reportes de analisis aprobado de ASV de los últimos 12 meses |
| 11.4.2/11.4.3 | Metodología documentada + alcance del trabajo + resultados de la prueba de penetracion (incluye retención mínima 12 meses) |
| 11.4.5/11.4.6 | Resultados de la prueba de penetracion sobre segmentación mostrando que el CDE está aislado |
| 11.5.2 | Configuración de FIM + reportes/alertas de monitoreo semanal |
| 11.6.1 | Configuración del mecanismo + registros de evaluación semanal o según TRA |
Errores comunes de examen
- Error: creer que el escaneo trimestral de 11.3.1 no exige reescaneo. Sí lo exige hasta confirmar resolución de todas las vulnerabilidades altas y criticas.
- Error: confundir prueba de penetracion con escaneo de vulnerabilidades. Son controles distintos con propósitos y evidencias diferentes.
- Error: olvidar que 11.4.2 y 11.4.3 también se activan tras cambio significativo, no solo anualmente.
- Error: creer que 11.4.5 aplica solo a proveedores de servicio. La prueba de segmentación aplica a todo el que usa segmentación; 11.4.6 es el adicional de SP (semestral).
- Error: confundir la frecuencia de FIM (semanal, fija) con la de deteccion de manipulaciones de pago (semanal o TRA).
Tema 6. Req 12.3.1: Analisis de riesgo especificos (TRA)
Regla del estándar
“Para cada requisito de PCI DSS que especifique la realización de un análisis de riesgos específicos, el análisis se documenta e incluye:
- Identificación de los activos protegidos.
- Identificación de la(s) amenaza(s) contra las que protege el requisito.
- Identificación de los factores que contribuyen a la probabilidad y/o impacto de que se materialice una amenaza.
- Análisis resultante que determina e incluye la justificación de cómo la frecuencia o los procesos definidos por la entidad para cumplir el requisito minimizan la probabilidad y/o el impacto de que se materialice la amenaza.
- Revisión de cada análisis de riesgos específicos al menos una vez cada 12 meses para determinar si los resultados siguen siendo válidos o si se necesita un análisis de riesgos actualizado.
- Realización de análisis de riesgos actualizados cuando sea necesario, según determine la revisión anual.” (PCI DSS v4.0.1, Req 12.3.1, p. 296 LA)
Nota de aplicabilidad: este requisito fue una práctica recomendada hasta el 31 de marzo de 2025; después de esa fecha es obligatorio y debe considerarse en su totalidad durante una evaluación PCI DSS. (PCI DSS v4.0.1, Req 12.3.1, p. 296 LA)
Para qué sirve la TRA en PCI DSS
La TRA en PCI DSS no es una evaluación de riesgo empresarial amplia. Es específica: permite a la entidad justificar la frecuencia de controles que el estándar describe como “periódicamente”, sin fijar un intervalo exacto. La entidad elige la frecuencia basándose en el riesgo documentado para su entorno.
Esta TRA es diferente de una evaluación de riesgos empresarial, que el estándar recomienda pero no exige. (PCI DSS v4.0.1, Req 12.3.1, p. 297 LA)
Requisitos que dependen de TRA (requieren Req 12.3.1)
Ver tabla completa en periodicity-bau-significant-change.md. Ejemplos representativos:
| Req | Control que depende de TRA |
|---|---|
| 11.3.1.1 | Frecuencia de remediación de vulnerabilidades de menor riesgo |
| 11.6.1 | Frecuencia de deteccion de manipulaciones (si se elige alternativa a semanal) |
| 12.6.2 | Frecuencia de revisión de políticas de seguridad |
| 8.6.3 | Frecuencia de rotación de passwords de cuentas de aplicación/sistema |
| 9.5.1.2.1 | Frecuencia de revisión de dispositivos POI |
| 10.4.2.1 | Frecuencia de revisión de logs no críticos |
Los cuatro elementos obligatorios de cada TRA
- Identificación de los activos protegidos.
- Identificación de la(s) amenaza(s) que el requisito protege.
- Identificación de factores que contribuyen a la probabilidad y/o impacto de que la amenaza se materialice.
- Análisis resultante que determina y justifica cómo la frecuencia o proceso definido por la entidad minimiza la probabilidad/impacto de la amenaza.
Más: revisión anual de cada TRA para validar si sigue siendo válida.
Lo que el assessor busca como evidencia
- Política/proceso que define cómo la entidad ejecuta TRAs.
- Para cada requisito con TRA: documento de TRA con los cuatro elementos, la frecuencia elegida y la justificación.
- Evidencia de revisión anual de cada TRA.
- Si la TRA fue actualizada: versión anterior y nueva, con justificación del cambio.
Errores comunes de examen
- Error: creer que “periodicamente” significa “anualmente”. Significa “según la TRA de la entidad”. La entidad puede elegir frecuencias distintas a 12 meses si las justifica en la TRA.
- Error: confundir Req 12.3.1 (TRA para actividades periódicas) con Req 12.3.2 (TRA para enfoque personalizado). Son TRAs con propósitos distintos.
- Error: presentar una evaluación de riesgo empresarial genérica como evidencia de TRA. Las TRAs de 12.3.1 son requisito-específicas.
- Error: olvidar que cada TRA debe revisarse al menos una vez cada 12 meses.
Tema 7. Req 12.5.2: confirmación anual del alcance PCI DSS
Regla del estándar
“El alcance PCI DSS se documenta y confirma por la entidad al menos una vez cada 12 meses y ante un cambio significativo en el entorno dentro del alcance.” (PCI DSS v4.0.1, Req 12.5.2, p. 305 LA)
La validación de alcance incluye, como mínimo:
- Identificar todos los flujos de datos para las distintas etapas de pago (autorización, captura, liquidación, contracargos, reembolsos) y canales de aceptación.
- Actualizar todos los diagramas de flujo de datos (Req 1.2.4).
- Identificar todas las ubicaciones donde se almacenan, procesan y transmiten datos de cuenta, incluyendo ubicaciones fuera del CDE definido, aplicaciones que procesan CHD, transmisiones entre sistemas y redes, y backups de archivos.
- Identificar todos los componentes del sistema en el CDE, conectados al CDE o que podrían impactar la seguridad del CDE.
- Identificar todos los controles de segmentación en uso y los entornos de los cuales el CDE está segmentado, incluyendo justificación de por qué esos entornos están fuera del alcance.
- Identificar todas las conexiones de terceros con acceso al CDE.
- Confirmar que todos los flujos de datos, datos de cuenta, componentes del sistema, controles de segmentación y conexiones de terceros identificados están incluidos en el alcance. (PCI DSS v4.0.1, Req 12.5.2, p. 305 LA)
Esta actividad NO reemplaza la confirmación de alcance del assessor
“Esta confirmación anual del alcance PCI DSS es una actividad que se espera que realice la entidad evaluada y no es lo mismo, ni pretende sustituir, a la confirmación del alcance realizada por el asesor de la entidad durante la evaluación anual.” (PCI DSS v4.0.1, Req 12.5.2, p. 306 LA)
Frecuencia y triggers
- Al menos una vez cada 12 meses (calendario).
- Ante cambio significativo al entorno dentro del alcance.
Nota: los cambios significativos deben también reflejarse en la confirmación de alcance (Req 6.5.2 hace referencia cruzada a Req 12.5.2).
Lo que el assessor busca como evidencia
- Resultados documentados de la revisión de alcance (puede ser un documento o registro formal).
- Entrevistas con personal que confirmen que las revisiones se realizaron.
- Que la revisión cubra todos los elementos listados en el requisito (flujos, ubicaciones, componentes del sistema, segmentación, terceros).
- Documentación de que los cambios significativos durante el año fueron incorporados.
Req 12.5.2.1 (solo SP): revisión adicional
“Requisito adicional solo para proveedores de servicios: el alcance PCI DSS se documenta y confirma por la entidad al menos una vez cada seis meses y ante un cambio significativo en el entorno dentro del alcance.” (PCI DSS v4.0.1, Req 12.5.2.1, p. 306-307 LA)
Los proveedores de servicio deben confirmar su alcance cada seis meses en lugar de cada 12 meses.
Errores comunes de examen
- Error: creer que la confirmación de alcance la realiza el assessor. La hace la entidad; el assessor valida que la entidad la realizó correctamente.
- Error: olvidar el trigger por cambio significativo. No basta con hacer la revisión anual.
- Error: olvidar que para proveedores de servicio la frecuencia es semestral (Req 12.5.2.1), no anual.
Tema 8. Evidencia: qué busca el assessor y cómo distinguir tipos
Los tres tipos de procedimiento de prueba
| Método | Qué hace el assessor |
|---|---|
| Examinar | Revisa documentos, configuraciones, registros, reportes, políticas |
| Observar | Observa procesos, actividades, mecanismos en operación |
| Entrevistar | Entrevista a personal responsable |
Una política bien documentada pero que nadie ejecuta solo satisface la evaluación documental de la política. El assessor necesita evidencia de operación real (logs, reportes, registros de actividades realizadas, entrevistas que confirmen cómo se ejecuta). (PCI DSS v4.0.1, sección “Metodos de prueba”, p. 31 LA)
Distinciones que confunden en examen
| Escenario de confusión | Distinción correcta |
|---|---|
| Política de patch management vs. registros de patches aplicados | La política es necesaria pero no suficiente. Se necesita evidencia de patches aplicados dentro de los plazos del Req 6.3.3. |
| Procedimiento de revisión de logs vs. registros de que la revisión ocurrió | El procedimiento documentado satisface la revisión del procedimiento. Los registros de revisión diaria satisfacen la revisión de registros. |
| Metodología de prueba de penetracion documentada vs. resultados de la prueba de penetracion | La metodología (Req 11.4.1) es un requisito separado de la ejecución de la prueba de penetracion (Req 11.4.2/11.4.3). |
| TRA documentada vs. evidencia de frecuencia ejecutada | La TRA justifica la frecuencia pero la evidencia de que la actividad se realizó a esa frecuencia es independiente. |
Errores comunes de examen
- Error: presentar una política o procedimiento como evidencia de que un control opera. Una política describe la intención; la evidencia de operación demuestra la ejecución.
- Error: confundir “definido” con “implementado”. El estándar distingue entre “processes are defined” (política/procedimiento) y “processes are implemented” (evidencia operacional).
- Error: olvidar que el assessor puede usar muestreo al revisar poblaciones grandes, pero la entidad no puede aplicar PCI DSS solo a una muestra de su entorno.
Definicion de cambio significativo (referencia)
“Hay varios requisitos que especifican las actividades que deben realizarse ante un cambio significativo en el entorno de una entidad. Si bien lo que constituye un cambio significativo depende en gran medida de la configuración de un entorno determinado, cada una de las siguientes actividades, como mínimo, tiene impactos potenciales en la seguridad del CDE y debe evaluarse para determinar si es un cambio significativo para una entidad en el contexto de los requisitos de PCI DSS relacionados:
- Nuevo hardware, software o equipo de red añadido al CDE.
- Cualquier sustitución o actualización importante de hardware y/o software en el CDE.
- Cualquier cambio en el flujo o almacenamiento de datos del titular de la tarjeta.
- Cualquier cambio en los límites del CDE y/o en el alcance de la evaluación PCI DSS.
- Cualquier cambio en la infraestructura de apoyo subyacente del CDE.
- Cualquier cambio en los vendedores/proveedores de servicios que apoyen el CDE o cumplan los requisitos de PCI DSS en nombre de la entidad.” (PCI DSS v4.0.1, seccion “Descripcion de los Plazos Utilizados en los Requisitos de PCI DSS”, p. 28 LA)
Resumen de alta prioridad para examen
| Tema | Trampa principal |
|---|---|
| Determinacion del alcance | ”Impacto en seguridad” como categoría dentro del alcance — no requiere contacto directo con CHD/SAD |
| SAD | No almacenable después de autorización, ni siquiera cifrado, incluso sin PAN |
| Segmentación | No es requisito del estándar; si se usa, debe probarse (11.4.5/11.4.6) |
| Req 6.4.2 | Desde 31/03/2025 solo solución automatizada es válida; no hay opción de revisión anual |
| Req 6.5.2 | Confirmar activamente PCI DSS tras cambio significativo, no solo documentar el cambio |
| Req 11.3.1 | Exige reescaneo hasta confirmar resolución de vulnerabilidades altas/críticas; trimestral es la frecuencia mínima |
| Req 11.4.5 vs. 11.4.6 | 11.4.5 = anual (todos); 11.4.6 = semestral (solo SP) |
| Req 12.3.1 | ”Periodically” ≠ anualmente; la TRA define la frecuencia y debe revisarse cada 12 meses |
| Req 12.5.2 | La entidad hace la confirmación de alcance; el assessor valida que la hizo |
| Evidencia | Política + evidencia de operación son requisitos separados |
Fuentes consultadas
- PCI DSS v4.0.1, sección “Alcance de los Requisitos de PCI DSS”, p. 9-10 LA
- PCI DSS v4.0.1, sección “Segmentacion”, p. 12 LA
- PCI DSS v4.0.1, sección “Confirmación Anual del Alcance PCI DSS”, p. 12 LA
- PCI DSS v4.0.1, Tabla 2 y Tabla 3 (requisitos de almacenamiento de los elementos de los datos del titular de la tarjeta), p. 4-6 LA
- PCI DSS v4.0.1, sección “Mejores Practicas para la Implementacion PCI DSS en Procesos Habituales”, p. 19-21 LA
- PCI DSS v4.0.1, sección “Descripcion de los Plazos Utilizados en los Requisitos de PCI DSS” (definición de cambio significativo), p. 25-26 LA
- PCI DSS v4.0.1, sección “Metodos de prueba”, p. 31 LA
- PCI DSS v4.0.1, Req 6.5.1, p. 155 LA
- PCI DSS v4.0.1, Req 6.5.2, p. 156 LA
- PCI DSS v4.0.1, Req 6.4.1, p. 150-151 LA
- PCI DSS v4.0.1, Req 6.4.2, p. 151-152 LA
- PCI DSS v4.0.1, Req 11.2.1, p. 261 LA
- PCI DSS v4.0.1, Req 11.3.1, p. 266 LA
- PCI DSS v4.0.1, Req 11.3.1.1, p. 268 LA
- PCI DSS v4.0.1, Req 11.3.1.2, p. 269 LA
- PCI DSS v4.0.1, Req 11.3.1.3, p. 270 LA
- PCI DSS v4.0.1, Req 11.3.2 y 11.3.2.1, p. 271-272 LA
- PCI DSS v4.0.1, Req 11.4.1, p. 274-275 LA
- PCI DSS v4.0.1, Req 11.4.2, p. 276 LA
- PCI DSS v4.0.1, Req 11.4.3, p. 277 LA
- PCI DSS v4.0.1, Req 11.4.4, p. 278 LA
- PCI DSS v4.0.1, Req 11.4.5, p. 279 LA
- PCI DSS v4.0.1, Req 11.4.6, p. 280 LA
- PCI DSS v4.0.1, Req 11.5.1, p. 283 LA
- PCI DSS v4.0.1, Req 11.5.1.1, p. 284 LA
- PCI DSS v4.0.1, Req 11.5.2, p. 286 LA
- PCI DSS v4.0.1, Req 11.6.1, p. 288 LA
- PCI DSS v4.0.1, Req 12.3.1, p. 296-297 LA
- PCI DSS v4.0.1, Req 12.5.2, p. 305-306 LA
periodicity-bau-significant-change.md(base canónica de periodicidades)recurring-activities-by-timeframe.md(vista por marco temporal)pci-isa-exam-guide.md(mindset de assessor y estrategia de examen)