Resumen de requisitos

Vista de estudio integral para repasar los 12 requisitos PCI DSS v4.0.1 con mentalidad ISA. Usala para ubicar rapidamente qué valida el assessor, qué evidencia pesa más y dónde suelen esconderse los distractores del examen.

Cómo usar esta guía

Primero lee cada requisito como mapa de estudio, no como reemplazo del estándar.
Para repaso de víspera, enfócate en periodicidades, [Solo SP], notas de aplicabilidad y confusiones.
Si una sección expone una brecha, salta al archivo especializado enlazado.
Contrasta cada trampa con flashcards.md, mock-questions.md y Examen_ISA_Extraido.md.

Req	Tema central	Mayor trampa de examen	Subcontroles SP-only típicos
1	Controles de seguridad de red	Confundir configuración documentada con operación revisada	No es el foco principal
2	Configuraciones seguras	Aceptar defaults o hardening genérico sin estándar aplicado	No es el foco principal
3	Datos almacenados	Creer que cifrar PAN siempre lo saca del alcance	No es el foco principal
4	Transmisión criptográfica	Confundir cifrado en tránsito con protección de datos almacenados	No es el foco principal
5	Software malicioso	Tratar monitoreo continuo y escaneo periódico como equivalentes sin nota de aplicabilidad	No es el foco principal
6	Software seguro	Confundir revisión de aplicación web, vulnerability scan y change control	No es el foco principal
7	Necesidad de saber	Mezclar cuentas de usuario con cuentas de aplicación/sistema	No es el foco principal
8	Identidad y autenticación	Aplicar reglas de contraseña sin leer si hay MFA o cuenta de sistema	No es el foco principal
9	Acceso físico	Confundir revocación inmediata con inventarios/revisiones anuales	No es el foco principal
10	Logs y monitoreo	Usar TRA para logs críticos que son diarios	10.7.1 fue solo SP hasta 31/03/2025
11	Testing técnico	Confundir ASV, scans internos, pen test y segmentación	11.4.6
12	Gobernanza	Creer que AOC de TPSP transfiere responsabilidad	12.4.2, 12.5.2.1

Requisito 1: Instalar y Mantener los Controles de Seguridad de la Red

Propósito

Restringir el tráfico hacia y desde el CDE mediante controles de seguridad de red definidos, configurados y mantenidos. El requisito cubre NSC, diagramas, flujos de datos y revisión periódica de reglas (PCI DSS v4.0.1, Req 1, p. 47 LA; Req 1.2.7, p. 48 LA).

Mindset ISA

El assessor valida que la arquitectura real coincide con diagramas, reglas y flujos aprobados. No basta ver una política de firewall: debe poder rastrear reglas, justificaciones, revisiones y cambios.

Subcontroles clave

1.2.4 mantiene diagramas de flujo de datos de cuenta actualizados; es base para scope y testing (PCI DSS v4.0.1, Req 1.2.4, p. 45 LA).
1.2.7 exige revisión de configuraciones de NSC al menos cada seis meses (PCI DSS v4.0.1, Req 1.2.7, p. 48 LA). Ver periodicity-bau-significant-change.md.
1.3.x restringe conexiones entrantes/salientes al CDE según necesidad de negocio (PCI DSS v4.0.1, Req 1.3, p. 51 LA).
1.4.x protege dispositivos confiables/no confiables y evita exposición directa del CDE (PCI DSS v4.0.1, Req 1.4, p. 57 LA).
1.5.1 exige que políticas y procedimientos del requisito estén documentados, en uso y conocidos por las partes afectadas (PCI DSS v4.0.1, Req 1.5.1, p. 61 LA).

Periodicidades y marcos temporales

Cada seis meses: revisión de configuraciones de NSC (1.2.7) (PCI DSS v4.0.1, Req 1.2.7, p. 48 LA).
En caso de evento: cambios de red deben actualizar diagramas, reglas y scope cuando alteran el CDE (1.2.4, 12.5.2) (PCI DSS v4.0.1, Req 1.2.4, p. 45 LA; Req 12.5.2, p. 304 LA).
Terminología de plazo: ver terminology-rules.md y recurring-activities-by-timeframe.md.

BAU vs evento puntual

La administración de reglas, revisión de cambios y actualización de diagramas es BAU. Un rediseño de segmentación o alta de nueva zona CDE es evento puntual que debe entrar por change control y puede disparar validaciones posteriores.

Disparadores de Significant Change

Cambios en NSC, topología o segmentación que modifican rutas hacia el CDE disparan revisión de reglas, diagramas y pruebas relacionadas (PCI DSS v4.0.1, Req 1.2.4, p. 45 LA; Req 6.5.2, p. 156 LA).
Nuevas conexiones de terceros o cambios de flujo de datos deben reflejarse en scope y documentación (PCI DSS v4.0.1, Req 12.5.2, p. 304 LA). Ver high-risk-topics.md.

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
1.2.4	Diagramas y flujos	Trazas/rutas reales	Dueño de red	Diagrama desactualizado pero reglas vigentes
1.2.7	Evidencia de revisión semestral	Consola NSC	Administrador NSC	Ticket de cambio sin revisión completa
1.3.x	Reglas y justificación	Configuración aplicada	Equipo red	Permisos amplios por conveniencia
1.4.x	Arquitectura y controles	Exposición desde redes no confiables	Arquitecto	Confundir DMZ con aislamiento probado

Trampas frecuentes

Trampa: aceptar diagramas como prueba de segmentación. Por qué se cae: los diagramas no prueban efectividad. Cómo distinguir: la segmentación se confirma con testing del Req 11.4.5/11.4.6.
Trampa: revisar solo reglas nuevas. Por qué se cae: 1.2.7 exige revisión de configuraciones de NSC. Cómo distinguir: buscar evidencia semestral completa (PCI DSS v4.0.1, Req 1.2.7, p. 48 LA).
Trampa: asumir que un firewall reduce scope por sí solo. Por qué se cae: el scope depende de conectividad, flujos y efectividad de controles. Cómo distinguir: validar alcance y pruebas de segmentación.

Confusiones con otros requisitos

1.2.4 vs 12.5.2 → diagramas de flujo como insumo técnico vs confirmación integral de scope.
1.2.7 vs 12.4.2 → revisión semestral de NSC vs revisión trimestral de operación de controles para service provider.
1.x vs 11.4.5 → diseño/configuración de red vs prueba de efectividad de segmentación.

Referencias cruzadas

periodicity-bau-significant-change.md filas 1.2.7 y 12.5.2.
recurring-activities-by-timeframe.md bloques semestral y anual.
high-risk-topics.md Tema 1 y Tema 7.
Flashcards: FC-023, FC-025, FC-076.
mock-questions.md P-027 y P-049.
study-plan-7-days.md Día 2.

Requisito 2: Aplicar Configuraciones Seguras a Todos los Componentes del Sistema

Propósito

Reducir superficie de ataque aplicando configuraciones seguras y eliminando configuraciones predeterminadas inseguras en todos los componentes del sistema (PCI DSS v4.0.1, Req 2, p. 71 LA; Req 2.2.1, p. 73 LA).

Mindset ISA

El assessor contrasta estándares de hardening aprobados contra configuraciones reales. Debe distinguir una plantilla documental de la evidencia de que los componentes fueron configurados conforme al estándar.

Subcontroles clave

2.2.1 exige estándares de configuración para componentes del sistema (PCI DSS v4.0.1, Req 2.2.1, p. 73 LA). Ver flashcards.md.
2.2.2 requiere gestionar servicios, protocolos y funciones inseguras o innecesarias (PCI DSS v4.0.1, Req 2.2.2, p. 74 LA).
2.2.4 permite solo servicios/protocolos necesarios y seguros, o justificados si son inseguros (PCI DSS v4.0.1, Req 2.2.4, p. 77 LA).
2.3.1 protege acceso administrativo no consola mediante criptografía robusta (PCI DSS v4.0.1, Req 2.3.1, p. 81 LA).
2.4.1 mantiene inventario de componentes del sistema dentro del alcance (PCI DSS v4.0.1, Req 2.4.1, p. 83 LA).

Periodicidades y marcos temporales

BAU continuo: aplicar estándares a nuevos componentes y cambios de configuración.
En caso de evento: cambios significativos deben confirmar que los requisitos aplicables siguen en vigor (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA).
Anual: la confirmación de scope usa inventario y componentes dentro del alcance (PCI DSS v4.0.1, Req 12.5.2, p. 304 LA).

BAU vs evento puntual

Hardening de builds, revisión de desviaciones y gestión de servicios son BAU. Migrar plataforma, cambiar imagen base o introducir un nuevo tipo de componente es evento que exige evidencia de aplicación del estándar.

Disparadores de Significant Change

Nuevos sistemas, imágenes base o servicios expuestos requieren validar configuración segura y documentación actualizada (PCI DSS v4.0.1, Req 2.2.1, p. 73 LA; Req 6.5.2, p. 156 LA).
Cambios de administración remota requieren confirmar uso de criptografía robusta para acceso administrativo no consola (PCI DSS v4.0.1, Req 2.3.1, p. 81 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
2.2.1	Estándares de configuración	Host configurado	Administrador plataforma	Estándar no aplicado
2.2.2	Lista de servicios	Servicios activos	Operaciones	Servicio “temporal” permanente
2.3.1	Configuración SSH/TLS/VPN	Acceso administrativo	Admin remoto	Protocolo cifrado débil
2.4.1	Inventario	CMDB/descubrimiento	Dueño de activos	Inventario incompleto del CDE

Trampas frecuentes

Trampa: creer que CIS/NIST genérico prueba cumplimiento. Por qué se cae: PCI exige que el estándar aplique a los componentes en scope. Cómo distinguir: mapear estándar, componente y evidencia.
Trampa: aceptar servicios inseguros por “legacy”. Por qué se cae: requieren justificación y controles de seguridad. Cómo distinguir: buscar razón documentada y mitigaciones.
Trampa: usar inventario de TI global como inventario PCI. Por qué se cae: puede no reflejar scope PCI. Cómo distinguir: cruzar con CDE, connected-to systems y flujos.

Confusiones con otros requisitos

2.2.1 vs 6.3.3 → configuración segura base vs instalación de parches.
2.4.1 vs 12.5.2 → inventario de componentes vs confirmación completa de scope.
2.3.1 vs 4.x → acceso administrativo cifrado vs transmisión de CHD por redes abiertas/públicas.

Referencias cruzadas

periodicity-bau-significant-change.md filas 6.5.2 y 12.5.2.
high-risk-topics.md Tema 3.
Flashcards: FC-077.
mock-questions.md P-006.
study-plan-7-days.md Día 2.

Requisito 3: Proteger los Datos del Titular de la Tarjeta Almacenados

Propósito

Minimizar y proteger datos de cuenta almacenados, incluyendo retención, eliminación, protección de PAN y restricciones sobre SAD (PCI DSS v4.0.1, Req 3, p. 85 LA; Req 3.2.1, p. 76 LA).

Mindset ISA

El assessor valida que la entidad sabe dónde almacena datos, por cuánto tiempo, cómo los elimina y cómo protege PAN. La respuesta de examen rara vez es “cifrar todo”; suele ser “retención, necesidad y evidencia”.

Subcontroles clave

3.2.1 exige proceso al menos trimestral para identificar y eliminar o inutilizar datos de cuenta que exceden retención (PCI DSS v4.0.1, Req 3.2.1, p. 76 LA). Ver periodicity-bau-significant-change.md.
3.3.x restringe almacenamiento de SAD después de autorización, con excepción acotada para emisores y servicios de emisión (PCI DSS v4.0.1, Req 3.3, p. 78 LA).
3.4.x controla visualización de PAN y acceso por necesidad de negocio (PCI DSS v4.0.1, Req 3.4, p. 86 LA).
3.5.1 exige que el PAN almacenado sea ilegible mediante métodos aceptados (PCI DSS v4.0.1, Req 3.5.1, p. 90 LA).
3.6.x protege claves criptográficas usadas para proteger datos de cuenta (PCI DSS v4.0.1, Req 3.6, p. 94 LA).

Periodicidades y marcos temporales

Trimestral: proceso de identificación y eliminación/inutilización de datos excedentes (3.2.1) (PCI DSS v4.0.1, Req 3.2.1, p. 76 LA).
BAU continuo: controles de visualización de PAN, almacenamiento SAD y protección criptográfica.
En caso de evento: cambios en almacenamiento, retención o cripto deben actualizar scope, procesos y evidencias.

BAU vs evento puntual

La minimización, masking y gestión de claves son BAU. Migrar repositorios, activar nuevos logs o cambiar arquitectura de tokenización es evento que exige confirmar dónde queda PAN y si los controles siguen aplicando.

Disparadores de Significant Change

Nuevo repositorio, flujo, backup o logging que pueda almacenar PAN dispara revisión de retención y descubrimiento de datos (PCI DSS v4.0.1, Req 3.2.1, p. 76 LA).
Cambio de método criptográfico o gestión de claves dispara validación de protección de PAN y procedimientos de claves (PCI DSS v4.0.1, Req 3.5.1, p. 90 LA; Req 3.6, p. 94 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
3.2.1	Procedimiento y ejecuciones trimestrales	Herramienta de discovery	Dueño de datos	Política sin ejecución
3.3.x	Configuración/app logs	Búsqueda SAD	Operaciones/app	SAD cifrado después de autorización
3.5.1	Diseño cripto/tokenización	PAN ilegible	Custodio de claves	Cifrado asumido como out of scope
3.6.x	Procedimientos de claves	HSM/KMS	Key custodians	Rotación documentada sin operación

Trampas frecuentes

Trampa: creer que SAD cifrado puede almacenarse después de autorización. Por qué se cae: SAD no se almacena después de autorización salvo excepciones acotadas. Cómo distinguir: identificar tipo de dato y momento.
Trampa: asumir que PAN cifrado sale del alcance. Por qué se cae: sistemas con capacidad de descifrar o procesar PAN siguen dentro del scope. Cómo distinguir: analizar llaves, procesos y acceso.
Trampa: confundir política de retención con eliminación real. Por qué se cae: 3.2.1 requiere proceso operativo al menos trimestral. Cómo distinguir: pedir evidencia de ejecución.

Confusiones con otros requisitos

3.2.1 vs A3.2.5 → eliminación de datos excedentes vs data discovery DESV.
3.5.1 vs 4.2.1 → PAN almacenado ilegible vs CHD cifrado en transmisión.
3.6.x vs 12.3.3 → gestión de claves vs revisión anual de cipher suites/protocolos.

Referencias cruzadas

periodicity-bau-significant-change.md fila 3.2.1.
recurring-activities-by-timeframe.md bloque trimestral.
pci-isa-exam-guide.md sección de alcance y cifrado.
Flashcards: FC-019, FC-020, FC-021, FC-022, FC-078, FC-079.
mock-questions.md P-034.
study-plan-7-days.md Día 5.

Requisito 4: Proteger los Datos de Tarjetahabiente con Criptografía Robusta Durante la Transmisión a través de Redes Abiertas y Públicas

Propósito

Proteger CHD durante transmisión sobre redes abiertas y públicas mediante criptografía robusta y configuraciones seguras (PCI DSS v4.0.1, Req 4, p. 124 LA; Req 4.2.1, p. 126 LA).

Mindset ISA

El assessor valida rutas de transmisión, protocolos reales y configuración efectiva. Debe distinguir protección en tránsito de protección en almacenamiento y no aceptar “usa TLS” sin versión, cipher suites y alcance.

Subcontroles clave

4.2.1 exige criptografía robusta para PAN transmitido por redes abiertas y públicas (PCI DSS v4.0.1, Req 4.2.1, p. 126 LA).
4.2.1.1 mantiene inventario de certificados y confirma que son válidos/no vencidos (PCI DSS v4.0.1, Req 4.2.1.1, p. 129 LA).
4.2.2 asegura que PAN no se envía sin protección por tecnologías de mensajería de usuario final (PCI DSS v4.0.1, Req 4.2.2, p. 131 LA).
12.3.3 revisa cipher suites y protocolos criptográficos al menos cada 12 meses (PCI DSS v4.0.1, Req 12.3.3, p. 298 LA).
2.3.1 cubre acceso administrativo no consola, que no reemplaza el análisis de CHD en tránsito (PCI DSS v4.0.1, Req 2.3.1, p. 81 LA).

Periodicidades y marcos temporales

Anual: revisión de cipher suites y protocolos criptográficos (12.3.3) (PCI DSS v4.0.1, Req 12.3.3, p. 298 LA).
BAU continuo: certificados válidos, protocolos seguros y no envío de PAN por mensajería insegura.
En caso de evento: cambios de endpoint, certificado o protocolo requieren validar transmisión protegida.

BAU vs evento puntual

La administración de certificados y monitoreo de configuraciones TLS es BAU. Cambiar gateway, proveedor, protocolo o cipher suite es evento que puede impactar scope y cumplimiento.

Disparadores de Significant Change

Migración de canal de pago, API pública o proveedor de comunicaciones exige revisar transmisión de CHD y certificados (PCI DSS v4.0.1, Req 4.2.1, p. 126 LA).
Cambio de protocolo/cipher suite debe reflejarse en revisión criptográfica y documentación (PCI DSS v4.0.1, Req 12.3.3, p. 298 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
4.2.1	Config TLS y diagramas	Prueba de endpoint	Arquitecto	TLS débil o ruta no cubierta
4.2.1.1	Inventario certificados	Certificados reales	Operaciones	Certificados vencidos/no inventariados
4.2.2	Políticas DLP/mensajería	Controles de correo/chat	Soporte	PAN enviado por canal usuario final
12.3.3	Revisión anual cripto	Config actual	Responsable cripto	Revisión anual sin remediación

Trampas frecuentes

Trampa: usar evidencia de cifrado en reposo para cumplir Req 4. Por qué se cae: Req 4 es transmisión. Cómo distinguir: seguir el flujo por red abierta/pública.
Trampa: aceptar “HTTPS” sin validar configuración. Por qué se cae: debe ser criptografía robusta. Cómo distinguir: revisar protocolos, certificados y cipher suites.
Trampa: ignorar mensajería de usuario final. Por qué se cae: 4.2.2 trata el envío de PAN por esas tecnologías. Cómo distinguir: revisar DLP, procesos y canales.

Confusiones con otros requisitos

4.2.1 vs 3.5.1 → transmisión por red abierta/pública vs PAN almacenado ilegible.
4.2.1 vs 2.3.1 → CHD en tránsito vs acceso administrativo no consola.
12.3.3 vs 3.6.x → revisión de protocolos/ciphers vs gestión de claves de protección de datos.

Referencias cruzadas

periodicity-bau-significant-change.md fila 12.3.3.
recurring-activities-by-timeframe.md bloque anual.
Flashcards: FC-113.
study-plan-7-days.md Día 5.

Requisito 5: Proteger Todos los Sistemas y Redes de Software Malicioso

Propósito

Prevenir, detectar y responder a software malicioso en sistemas y redes dentro del alcance, usando mecanismos apropiados según riesgo y aplicabilidad (PCI DSS v4.0.1, Req 5, p. 133 LA; Req 5.2.3, p. 123 LA).

Mindset ISA

El assessor debe verificar cobertura, operación y respuesta, no solo presencia de agente anti-malware. El examen suele preguntar cuándo aplica escaneo periódico frente a monitoreo continuo.

Subcontroles clave

5.2.3 requiere evaluaciones periódicas para componentes no comúnmente afectados por malware (PCI DSS v4.0.1, Req 5.2.3, p. 123 LA).
5.3.2 exige mecanismos anti-malware activos, actualizados y capaces de generar logs (PCI DSS v4.0.1, Req 5.3.2, p. 126 LA).
5.3.2.1 aplica cuando se usan escaneos periódicos en vez de monitoreo continuo (PCI DSS v4.0.1, Req 5.3.2.1, p. 127 LA).
5.3.3 evita que usuarios deshabiliten o alteren mecanismos anti-malware salvo autorización específica (PCI DSS v4.0.1, Req 5.3.3, p. 129 LA).
10.7.2 cubre detección y respuesta a fallas de sistemas críticos de control de seguridad, incluido anti-malware (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA).

Periodicidades y marcos temporales

Periódicamente: evaluaciones de componentes no comúnmente afectados por malware según riesgo/TRA cuando aplique (PCI DSS v4.0.1, Req 5.2.3, p. 123 LA).
BAU continuo: mecanismos anti-malware activos y actualizados.
Con prontitud: respuesta a fallas de controles críticos según Req 10.7.2/10.7.3 (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA; Req 10.7.3, p. 257 LA).

BAU vs evento puntual

La operación de anti-malware y alertas es BAU. Cambiar plataforma, excluir directorios o deshabilitar agente en un sistema CDE es evento que requiere aprobación y evidencia.

Disparadores de Significant Change

Nuevo sistema operativo, plataforma o carga de trabajo requiere reevaluar si es comúnmente afectado por malware (PCI DSS v4.0.1, Req 5.2.3, p. 123 LA).
Cambios de herramienta anti-malware o exclusiones amplias requieren validar cobertura y respuesta ante fallas (PCI DSS v4.0.1, Req 5.3.2, p. 126 LA; Req 10.7.2, p. 256 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
5.2.3	Evaluación de riesgo	Cobertura por plataforma	Seguridad endpoint	Suposición de “no aplica”
5.3.2	Configuración agente	Consola anti-malware	Operaciones	Agente instalado pero inactivo
5.3.2.1	Calendario de scans	Últimos scans	Admin endpoint	Escaneo periódico donde se exige continuo
5.3.3	Controles de bloqueo	Intento/config usuario	Soporte	Usuarios pueden deshabilitar

Trampas frecuentes

Trampa: asumir que Linux/Unix nunca requiere evaluación. Por qué se cae: debe evaluarse susceptibilidad a malware. Cómo distinguir: pedir análisis documentado.
Trampa: confundir monitoreo continuo con escaneo periódico. Por qué se cae: 5.3.2.1 depende de la opción usada. Cómo distinguir: leer nota de aplicabilidad y configuración real.
Trampa: aceptar consola con equipos “offline”. Por qué se cae: el mecanismo debe operar y generar logs. Cómo distinguir: revisar estado, firmas y alertas.

Confusiones con otros requisitos

5.3.2.1 vs 11.3.1 → escaneo malware vs vulnerability scan interno.
5.x vs 10.7.2 → control anti-malware vs detección/respuesta a falla del control.
5.2.3 vs 12.3.1 → evaluación de exposición a malware vs TRA para frecuencias periódicas.

Referencias cruzadas

periodicity-bau-significant-change.md filas 5.2.3, 5.3.2.1, 10.7.2.
Flashcards: FC-080, FC-081.
pci-isa-exam-guide.md sección notas de aplicabilidad.
study-plan-7-days.md Día 5.

Requisito 6: Desarrollar y Mantener Sistemas y Softwares Seguros

Propósito

Reducir vulnerabilidades mediante gestión de parches, desarrollo seguro, revisión de código, protección de aplicaciones públicas y control de cambios (PCI DSS v4.0.1, Req 6, p. 149 LA; Req 6.5.2, p. 156 LA).

Mindset ISA

El assessor valida ciclo de vida y evidencia: clasificación de vulnerabilidades, parches aplicados, revisiones independientes, controles sobre aplicaciones públicas y confirmación tras cambios.

Subcontroles clave

6.2.2 exige inventario y revisión de componentes de software a medida/personalizado al menos cada 12 meses (PCI DSS v4.0.1, Req 6.2.2, p. 137 LA).
6.2.3 requiere revisión de código antes de producción o entrega al cliente (PCI DSS v4.0.1, Req 6.2.3, p. 138 LA).
6.2.3.1 exige independencia cuando la revisión de código es manual (PCI DSS v4.0.1, Req 6.2.3.1, p. 138 LA).
6.4.2 exige solución técnica automatizada para aplicaciones web públicas desde el 31/03/2025 (PCI DSS v4.0.1, Req 6.4.2, p. 151-152 LA).
6.5.2 exige confirmar que requisitos PCI DSS aplicables siguen en vigor tras cambio significativo (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA).

Periodicidades y marcos temporales

Anual: revisión de software a medida/personalizado (6.2.2) (PCI DSS v4.0.1, Req 6.2.2, p. 137 LA).
En caso de evento: cambios significativos activan 6.5.2 (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA).
Continuo/BAU: gestión de vulnerabilidades, desarrollo seguro, controles de aplicaciones públicas.

BAU vs evento puntual

Patching, revisión de código y gestión de vulnerabilidades son BAU. Un release mayor, nueva aplicación pública o cambio de arquitectura es evento que requiere evidencia de change control y confirmación PCI DSS.

Disparadores de Significant Change

Nuevas aplicaciones, cambios en CDE, actualizaciones mayores de infraestructura o aplicación disparan confirmación activa de requisitos aplicables (PCI DSS v4.0.1, Req 6.5.2, p. 156 LA).
Cambios en aplicación web pública deben mantener la protección automatizada de 6.4.2 (PCI DSS v4.0.1, Req 6.4.2, p. 151-152 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
6.2.2	Inventario/revisión anual	Repositorios	AppSec	Inventario incompleto
6.2.3	Registros de code review	Pull request/tool	Desarrollador	Autor revisa su propio código
6.4.2	WAF/RASP/config	Tráfico protegido	App owner	Usar revisión manual post-2025
6.5.2	Ticket de cambio y checklist PCI	Cambio desplegado	Change manager	Ticket sin confirmación PCI

Trampas frecuentes

Trampa: aceptar ticket de cambio como cumplimiento de 6.5.2. Por qué se cae: el requisito pide confirmar requisitos aplicables y actualizar documentación. Cómo distinguir: buscar checklist/evidencia PCI.
Trampa: creer que después del 31/03/2025 sigue la opción de revisión manual anual para 6.4.2. Por qué se cae: la opción válida es solución automatizada. Cómo distinguir: validar fecha y nota de aplicabilidad.
Trampa: confundir 6.4.2 con vulnerability scans 11.3.x. Por qué se cae: son controles distintos. Cómo distinguir: aplicación web pública vs escaneo de vulnerabilidades.

Confusiones con otros requisitos

6.4.2 vs 11.3.1/11.3.2 → protección automatizada de app pública vs escaneos de vulnerabilidad.
6.5.2 vs 11.3.1.3/11.3.2.1 → confirmación PCI tras cambio vs scans post-cambio.
6.2.3 vs 6.2.3.1 → revisión de código vs independencia si la revisión es manual.

Referencias cruzadas

high-risk-topics.md Temas 3 y 4.
periodicity-bau-significant-change.md filas 6.2.2, 6.4.2, 6.5.2.
Flashcards: FC-082 a FC-088.
mock-questions.md P-035, P-036, P-037.
study-plan-7-days.md Día 5.

Requisito 7: Restringir el Acceso a los Componentes del Sistema y a los Datos de Tarjetahabiente Según la Necesidad de Saber del Negocio

Propósito

Asegurar que el acceso lógico a componentes y CHD se limita a usuarios, cuentas y procesos con necesidad legítima de negocio (PCI DSS v4.0.1, Req 7, p. 176 LA; Req 7.2.4, p. 167 LA).

Mindset ISA

El assessor valida modelo de autorización, aprobación, revisión y remediación. La evidencia fuerte es ejecución de revisiones y correcciones, no solo matriz de roles.

Subcontroles clave

7.2.1 define modelo de acceso basado en necesidad de saber y menor privilegio (PCI DSS v4.0.1, Req 7.2.1, p. 163 LA).
7.2.2 asigna acceso según roles y responsabilidades (PCI DSS v4.0.1, Req 7.2.2, p. 164 LA).
7.2.4 revisa cuentas de usuario y privilegios al menos cada seis meses (PCI DSS v4.0.1, Req 7.2.4, p. 167 LA). Ver periodicity-bau-significant-change.md.
7.2.5.1 revisa cuentas de aplicación/sistema y privilegios periódicamente según TRA (PCI DSS v4.0.1, Req 7.2.5.1, p. 169 LA).
7.3.1 requiere que políticas/procedimientos estén documentados, en uso y conocidos (PCI DSS v4.0.1, Req 7.3.1, p. 171 LA).

Periodicidades y marcos temporales

Cada seis meses: revisión de cuentas de usuario y privilegios (7.2.4) (PCI DSS v4.0.1, Req 7.2.4, p. 167 LA).
Periódicamente según TRA: revisión de cuentas de aplicación/sistema (7.2.5.1) (PCI DSS v4.0.1, Req 7.2.5.1, p. 169 LA).
BAU: aprobación, provisión y remediación de accesos.

BAU vs evento puntual

Altas, bajas, cambios de rol y remediación de accesos son BAU. Reorganizaciones, cambios de IAM o migración de aplicaciones son eventos que requieren revisar roles y privilegios.

Disparadores de Significant Change

Cambio de IAM, modelo de roles o aplicación crítica requiere validar necesidad de saber y revisiones aplicables (PCI DSS v4.0.1, Req 7.2.1, p. 163 LA).
Cambio de cuentas de aplicación/sistema requiere revisar ownership, privilegios y frecuencia definida por TRA (PCI DSS v4.0.1, Req 7.2.5.1, p. 169 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
7.2.1	Matriz de roles	Permisos reales	Dueño de proceso	Roles demasiado amplios
7.2.4	Registros de revisión	IAM/reportes	Revisor	Revisión sin remediación
7.2.5.1	TRA y revisión	Cuentas sistema	App owner	Tratar cuentas sistema como usuarios
7.3.1	Procedimientos	Uso real	Personal afectado	Procedimiento no conocido

Trampas frecuentes

Trampa: confundir revisión semestral de usuarios con revisión por TRA de cuentas de aplicación. Por qué se cae: sujetos y frecuencia son distintos. Cómo distinguir: usuario humano vs cuenta sistema.
Trampa: aceptar aprobación inicial como revisión periódica. Por qué se cae: 7.2.4 pide revisión recurrente. Cómo distinguir: buscar evidencia dentro del periodo evaluado.
Trampa: no verificar remediación de accesos inapropiados. Por qué se cae: la revisión debe confirmar que el acceso es apropiado. Cómo distinguir: seguir hallazgos hasta cierre.

Confusiones con otros requisitos

7.2.4 vs 8.2.6 → revisión semestral de acceso vs desactivación por 90 días de inactividad.
7.2.5.1 vs 8.6.3 → revisión de privilegios de cuentas sistema vs cambio de contraseñas de esas cuentas.
7.x vs 12.4.2 → control de acceso vs revisión operativa trimestral de service provider.

Referencias cruzadas

periodicity-bau-significant-change.md filas 7.2.4 y 7.2.5.1.
recurring-activities-by-timeframe.md bloques semestral y TRA.
Flashcards: FC-065, FC-089, FC-090.
mock-questions.md P-002 y P-038.
study-plan-7-days.md Día 5.

Requisito 8: Identificar a los Usuarios y Autenticar el Acceso a los Componentes del Sistema

Propósito

Garantizar que cada usuario se identifica de forma única y que el acceso a componentes del sistema se autentica de forma adecuada (PCI DSS v4.0.1, Req 8, p. 190 LA; Req 8.2.5, p. 181 LA).

Mindset ISA

El assessor busca trazabilidad de identidad, autenticación efectiva y lifecycle de cuentas. El examen castiga respuestas que aplican reglas de contraseña sin leer notas de aplicabilidad.

Subcontroles clave

8.2.5 exige revocar inmediatamente el acceso lógico de usuarios terminados (PCI DSS v4.0.1, Req 8.2.5, p. 181 LA).
8.2.6 deshabilita o elimina cuentas inactivas dentro de 90 días (PCI DSS v4.0.1, Req 8.2.6, p. 182 LA).
8.3.5 cambia contraseñas/passphrases iniciales o reseteadas inmediatamente después del primer uso (PCI DSS v4.0.1, Req 8.3.5, p. 193 LA).
8.3.9 aplica cambio cada 90 días si contraseña/passphrase es el único factor de autenticación (PCI DSS v4.0.1, Req 8.3.9, p. 192 LA).
8.6.3 cambia contraseñas/passphrases de cuentas de aplicación/sistema según TRA y ante sospecha/confirmación de compromiso (PCI DSS v4.0.1, Req 8.6.3, p. 207 LA).

Periodicidades y marcos temporales

Inmediatamente: revocación de usuarios terminados (8.2.5) y cambio tras primer uso (8.3.5) (PCI DSS v4.0.1, Req 8.2.5, p. 181 LA; Req 8.3.5, p. 193 LA).
Dentro de 90 días: cuentas inactivas (8.2.6) y contraseñas single-factor (8.3.9) (PCI DSS v4.0.1, Req 8.2.6, p. 182 LA; Req 8.3.9, p. 192 LA).
Periódicamente según TRA: cuentas de aplicación/sistema (8.6.3) (PCI DSS v4.0.1, Req 8.6.3, p. 207 LA).

BAU vs evento puntual

Joiner/mover/leaver, monitoreo de inactividad y reset de credenciales son BAU. Sospecha de compromiso de cuenta sistema es evento que exige cambio inmediato además del ciclo definido por TRA.

Disparadores de Significant Change

Cambio de proveedor IAM/MFA o política de autenticación requiere validar aplicabilidad de 8.3.9 y otros controles (PCI DSS v4.0.1, Req 8.3.9, p. 192 LA).
Sospecha o confirmación de compromiso de cuenta de aplicación/sistema dispara cambio de contraseña/passphrase (PCI DSS v4.0.1, Req 8.6.3, p. 207 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
8.2.5	Casos de terminación	Estado cuentas	HR/IAM	Revocación en ciclo batch tardío
8.2.6	Reporte inactividad	IAM	Admin IAM	Cuentas bloqueadas pero no deshabilitadas
8.3.9	Política auth	Config MFA/password	IAM	Aplicar 90 días pese a MFA
8.6.3	TRA y procedimiento	Vault/config	App owner	Cuenta sistema sin owner

Trampas frecuentes

Trampa: interpretar “inmediatamente” como 24 horas. Por qué se cae: significa sin demora. Cómo distinguir: evidencia de revocación al terminar la relación.
Trampa: aplicar cambio cada 90 días a cuentas con MFA sin leer aplicabilidad. Por qué se cae: 8.3.9 aplica cuando contraseña es único factor. Cómo distinguir: validar método de autenticación.
Trampa: tratar cuentas de aplicación como usuarios humanos. Por qué se cae: tienen controles y revisión distintos. Cómo distinguir: cruzar 7.2.5.1 y 8.6.3.

Confusiones con otros requisitos

8.2.5 vs 8.2.6 → terminación inmediata vs inactividad dentro de 90 días.
8.3.9 vs 8.6.3 → usuario single-factor vs cuenta de aplicación/sistema.
8.x vs 7.x → autenticación/identidad vs autorización/necesidad de saber.

Referencias cruzadas

periodicity-bau-significant-change.md filas 8.2.5, 8.2.6, 8.3.5, 8.3.9, 8.6.3.
Flashcards: FC-091 a FC-095, FC-118, FC-120.
mock-questions.md P-022, P-023, P-039, P-040, P-041.
study-plan-7-days.md Día 5.

Requisito 9: Restringir el Acceso Físico a los Datos de Tarjetahabiente

Propósito

Proteger físicamente CHD, medios, dispositivos y áreas sensibles mediante controles de acceso, monitoreo, inventario y destrucción segura (PCI DSS v4.0.1, Req 9, p. 226 LA; Req 9.3.1.1, p. 217 LA).

Mindset ISA

El assessor valida que controles físicos operan en ubicaciones reales: badges, visitantes, medios, backups offline y POI. Las entrevistas deben corroborarse con registros e inspección.

Subcontroles clave

9.3.1.1 revoca inmediatamente acceso físico a áreas sensibles al terminar relación (PCI DSS v4.0.1, Req 9.3.1.1, p. 217 LA).
9.4.1.2 revisa seguridad de ubicaciones de backup de medios físicos offline al menos cada 12 meses (PCI DSS v4.0.1, Req 9.4.1.2, p. 221 LA).
9.4.5.1 inventaría medios electrónicos con CHD al menos cada 12 meses (PCI DSS v4.0.1, Req 9.4.5.1, p. 224 LA).
9.5.1.2 exige inspección periódica de superficies de dispositivos POI (PCI DSS v4.0.1, Req 9.5.1.2, p. 230 LA).
9.5.1.2.1 define frecuencia y tipo de inspección POI mediante TRA (PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA).

Periodicidades y marcos temporales

Inmediatamente: revocación de acceso físico al terminar relación (9.3.1.1) (PCI DSS v4.0.1, Req 9.3.1.1, p. 217 LA).
Anual: revisión de ubicaciones de backup offline e inventario de medios (9.4.1.2, 9.4.5.1) (PCI DSS v4.0.1, Req 9.4.1.2, p. 221 LA; Req 9.4.5.1, p. 224 LA).
Periódicamente según TRA: frecuencia/tipo de inspecciones POI (9.5.1.2.1) (PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA).

BAU vs evento puntual

Gestión de visitantes, acceso físico y POI es BAU. Apertura de sitio, mudanza de backup o reemplazo masivo de POI es evento que debe actualizar inventarios, procedimientos y evidencia.

Disparadores de Significant Change

Nuevo sitio, nueva ubicación de backup o cambio de proveedor físico debe entrar en scope y controles de acceso/medios (PCI DSS v4.0.1, Req 9.4.1.2, p. 221 LA; Req 12.5.2, p. 304 LA).
Cambio de tipo de dispositivo POI o entorno físico puede requerir revisar TRA de frecuencia/tipo de inspección (PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
9.3.1.1	Casos offboarding	Badge/access system	Seguridad física	Badge devuelto pero acceso activo
9.4.1.2	Revisión anual backup	Ubicación backup	Custodio medios	Revisión documental sin ubicación
9.4.5.1	Inventario medios	Conteo físico	Responsable medios	Inventario no conciliado
9.5.1.2.1	TRA POI	Dispositivos POI	Operaciones tienda	Frecuencia no justificada

Trampas frecuentes

Trampa: confundir revocación lógica con física. Por qué se cae: 8.2.5 y 9.3.1.1 son paralelos pero distintos. Cómo distinguir: IAM vs badges/llaves/accesos físicos.
Trampa: aceptar lista de POI sin inspecciones. Por qué se cae: inventario y revisión visual son evidencias distintas. Cómo distinguir: pedir registros de inspección.
Trampa: tratar “periódicamente” como anual por costumbre. Por qué se cae: frecuencia de POI se justifica por TRA. Cómo distinguir: revisar 12.3.1.

Confusiones con otros requisitos

9.3.1.1 vs 8.2.5 → acceso físico vs acceso lógico.
9.4.5.1 vs 3.2.1 → inventario de medios con CHD vs eliminación de datos excedentes.
9.5.1.2.1 vs 12.3.1 → requisito que usa frecuencia periódica vs proceso que justifica esa frecuencia.

Referencias cruzadas

periodicity-bau-significant-change.md filas 9.3.1.1, 9.4.1.2, 9.4.5.1, 9.5.1.2.1.
recurring-activities-by-timeframe.md bloques inmediato, anual y TRA.
Flashcards: FC-067, FC-096, FC-097, FC-098.
mock-questions.md P-024 y P-025.
study-plan-7-days.md Día 5.

Requisito 10: Registrar y Supervisar Todos los Accesos a los Componentes del Sistema y a los Datos de Tarjetahabiente

Propósito

Generar, proteger, revisar y retener audit logs para detectar actividad sospechosa y reconstruir eventos relevantes sobre sistemas y CHD (PCI DSS v4.0.1, Req 10, p. 250 LA; Req 10.4.1, p. 246 LA).

Mindset ISA

El assessor valida que los logs existen, son completos, están protegidos y se revisan con la frecuencia correcta. La política de revisión no sustituye registros de revisión ejecutada.

Subcontroles clave

10.4.1 exige revisión diaria de logs críticos y eventos de seguridad (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA).
10.4.2 revisa otros logs periódicamente según TRA (PCI DSS v4.0.1, Req 10.4.2, p. 248 LA; Req 10.4.2.1, p. 249 LA).
10.5.1 retiene audit logs al menos 12 meses y mantiene 3 meses disponibles inmediatamente (PCI DSS v4.0.1, Req 10.5.1, p. 251 LA).
10.7.2 detecta fallas de sistemas críticos de control de seguridad con prontitud (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA).
10.7.3 documenta respuesta, causa, duración y acciones correctivas ante fallas (PCI DSS v4.0.1, Req 10.7.3, p. 257 LA).

Periodicidades y marcos temporales

Diario: revisión de logs críticos (10.4.1) (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA).
Periódicamente según TRA: otros logs (10.4.2) (PCI DSS v4.0.1, Req 10.4.2, p. 248 LA).
Retención: al menos 12 meses; 3 meses disponibles inmediatamente (10.5.1) (PCI DSS v4.0.1, Req 10.5.1, p. 251 LA).
Con prontitud: detectar/responder a fallas críticas (10.7.2, 10.7.3) (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA; Req 10.7.3, p. 257 LA).

BAU vs evento puntual

Ingesta, revisión diaria, alertamiento y retención son BAU. Caída del SIEM, falla de FIM o pérdida de logs es evento que exige respuesta documentada.

Disparadores de Significant Change

Nuevo sistema CDE, nueva fuente de logs o cambio de SIEM requiere confirmar cobertura, revisión y retención (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA; Req 10.5.1, p. 251 LA).
Falla de sistema crítico de control de seguridad dispara detección y respuesta con prontitud (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
10.4.1	Registros de revisión diaria	Consola SIEM	SOC	Solo política de revisión
10.4.2	TRA y revisiones	Logs no críticos	Analista	TRA usada para logs críticos
10.5.1	Config retención	Búsqueda histórica	SIEM admin	12 meses no recuperables
10.7.3	Incidentes de falla	Alertas	Operaciones	Falla sin causa/duración

Trampas frecuentes

Trampa: revisar logs críticos solo en días hábiles. Por qué se cae: diario significa todos los días del año. Cómo distinguir: muestrear fines de semana/feriados.
Trampa: usar TRA para reducir frecuencia de 10.4.1. Por qué se cae: TRA aplica a 10.4.2. Cómo distinguir: clasificar fuente crítica vs otros componentes.
Trampa: confundir retención con disponibilidad inmediata. Por qué se cae: 10.5.1 exige ambas cosas. Cómo distinguir: probar acceso a últimos 3 meses.

Confusiones con otros requisitos

10.4.1 vs 10.4.2 → logs críticos diarios vs otros logs por TRA.
10.7.2 vs 10.7.3 → detección de falla vs respuesta documentada.
10.x vs 12.10.x → monitoreo/logs vs plan formal de respuesta a incidentes.

Referencias cruzadas

periodicity-bau-significant-change.md filas 10.4.1, 10.4.2, 10.5.1, 10.7.2, 10.7.3.
recurring-activities-by-timeframe.md bloques diario, TRA y con prontitud.
Flashcards: FC-051, FC-064, FC-099 a FC-103.
mock-questions.md P-017, P-042, P-043.
study-plan-7-days.md Día 6.

Requisito 11: Poner a Prueba Regularmente la Seguridad de los Sistemas y de las Redes

Propósito

Validar regularmente que sistemas y redes son seguros mediante detección wireless, vulnerability scans, pruebas de penetración, segmentación, IDS/IPS, FIM y detección de cambios en páginas de pago (PCI DSS v4.0.1, Req 11, p. 274 LA).

Mindset ISA

El assessor verifica frecuencias correctas, alcance correcto y evidencia de remediación. Debe distinguir metodología documentada, scan interno, scan externo ASV, pen test y prueba de segmentación.

Subcontroles clave

11.2.1 detecta puntos de acceso inalámbrico no autorizados al menos trimestralmente o por monitoreo continuo (PCI DSS v4.0.1, Req 11.2.1, p. 262 LA).
11.3.1 ejecuta vulnerability scans internos al menos trimestralmente (PCI DSS v4.0.1, Req 11.3.1, p. 265 LA).
11.3.2 ejecuta vulnerability scans externos trimestrales por ASV con análisis aprobado (PCI DSS v4.0.1, Req 11.3.2, p. 270 LA).
11.4.2 y 11.4.3 ejecutan pruebas de penetración internas y externas al menos anualmente y tras cambio significativo (PCI DSS v4.0.1, Req 11.4.2, p. 276 LA; Req 11.4.3, p. 277 LA).
11.4.6 exige prueba de controles de segmentación al menos cada seis meses para service provider [Solo SP] (PCI DSS v4.0.1, Req 11.4.6, p. 280 LA).
11.6.1 detecta cambios/manipulación en headers HTTP y scripts de páginas de pago al menos semanalmente o por TRA (PCI DSS v4.0.1, Req 11.6.1, p. 287 LA).

Periodicidades y marcos temporales

Trimestral: wireless y scans internos/externos (11.2.1, 11.3.1, 11.3.2) (PCI DSS v4.0.1, Req 11.2.1, p. 262 LA; Req 11.3.1, p. 265 LA; Req 11.3.2, p. 270 LA).
Anual y tras cambio significativo: pen tests internos/externos y segmentación para entidades no SP (11.4.2, 11.4.3, 11.4.5) (PCI DSS v4.0.1, Req 11.4.2, p. 276 LA; Req 11.4.5, p. 279 LA).
Cada seis meses y tras cambios en segmentación: 11.4.6 [Solo SP] (PCI DSS v4.0.1, Req 11.4.6, p. 280 LA).
Semanal o según TRA: 11.6.1 (PCI DSS v4.0.1, Req 11.6.1, p. 287 LA).

BAU vs evento puntual

IDS/IPS, FIM y detección en páginas de pago son BAU. Scans, pen tests y pruebas de segmentación son eventos calendarizados que también se disparan por cambios significativos.

Disparadores de Significant Change

Cambios mayores de infraestructura/aplicación disparan pen tests internos/externos (PCI DSS v4.0.1, Req 11.4.2, p. 276 LA; Req 11.4.3, p. 277 LA).
Cambios en controles o métodos de segmentación disparan pruebas de segmentación (11.4.5, 11.4.6) (PCI DSS v4.0.1, Req 11.4.5, p. 279 LA; Req 11.4.6, p. 280 LA).
Cambios significativos disparan scans post-cambio internos/externos (11.3.1.3, 11.3.2.1) (PCI DSS v4.0.1, Req 11.3.1.3, p. 269 LA; Req 11.3.2.1, p. 272 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
11.3.2	Reporte ASV aprobado	—	Responsable vuln mgmt	Scan externo no-ASV
11.4.1	Metodología documentada	—	Equipo de pen test	Metodología sin ejecución
11.4.5	Resultados segmentación	Rutas/alcance	Tester	Confundir con 11.4.6
11.5.1	Config IDS/IPS	Alertas activas	SOC	Herramienta instalada sin operación
11.6.1	Config mecanismo	Cambio detectado	E-commerce	Detectar servidor, no browser

Trampas frecuentes

Trampa: aceptar scan interno donde se requiere ASV externo. Por qué se cae: 11.3.2 requiere ASV. Cómo distinguir: ASV aplica al externo trimestral, no al post-cambio 11.3.2.1.
Trampa: confundir 11.4.5 con 11.4.6. Por qué se cae: ambos son segmentación. Cómo distinguir: anual todos vs semestral [Solo SP].
Trampa: validar metodología 11.4.1 y asumir ejecución. Por qué se cae: ejecución está en 11.4.2/11.4.3. Cómo distinguir: pedir resultados y remediación.
Trampa: creer que si no hay segmentación se incumple 11.4.5. Por qué se cae: aplica si se usa segmentación para reducir scope. Cómo distinguir: si no hay segmentación, más red queda en scope.

Confusiones con otros requisitos

11.3.1 vs 11.3.2 → interno sin ASV vs externo con ASV.
11.3.1.3 vs 11.3.2.1 → scans post-cambio interno/externo; el externo post-cambio no exige ASV.
11.4.1 vs 11.4.2/11.4.3 → metodología vs ejecución.
11.4.5 vs 11.4.6 → anual todos vs semestral [Solo SP].

Referencias cruzadas

high-risk-topics.md Tema 5.
periodicity-bau-significant-change.md filas 11.2.1 a 11.6.1.
reporting-and-testing.md §2.
Flashcards: FC-052, FC-068, FC-104 a FC-111, FC-119.
mock-questions.md P-014, P-020, P-044 a P-049.
study-plan-7-days.md Día 6.

Requisito 12: Respaldar la Seguridad de la Información con Políticas y Programas Organizacionales

Propósito

Sostener el programa PCI DSS mediante políticas, gobernanza, TRA, revisiones, awareness, TPSP y respuesta a incidentes (PCI DSS v4.0.1, Req 12, p. 307 LA; Req 12.3.1, p. 295 LA).

Mindset ISA

El assessor valida que la organización mantiene cumplimiento como programa operativo. Este requisito suele definir quién es responsable, qué se revisa y con qué frecuencia se justifica “periódicamente”.

Subcontroles clave

12.1.1 revisa la política general de seguridad al menos cada 12 meses (PCI DSS v4.0.1, Req 12.1.1, p. 290 LA).
12.3.1 exige proceso de TRA para requisitos con frecuencia “periódicamente” y revisión al menos anual (PCI DSS v4.0.1, Req 12.3.1, p. 295 LA).
12.3.2 exige TRA para cada control implementado mediante enfoque personalizado (PCI DSS v4.0.1, Req 12.3.2, p. 297 LA).
12.4.2 exige revisiones trimestrales de actividades operativas de seguridad para service provider [Solo SP] (PCI DSS v4.0.1, Req 12.4.2, p. 301 LA).
12.5.2.1 exige confirmación de scope al menos cada seis meses para service provider [Solo SP] (PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA).
12.8.4 monitorea cumplimiento de TPSP al menos anualmente (PCI DSS v4.0.1, Req 12.8.4, p. 318 LA).
12.10.2 revisa y prueba el plan de respuesta a incidentes al menos anualmente (PCI DSS v4.0.1, Req 12.10.2, p. 327 LA).

Periodicidades y marcos temporales

Anual: política, TRA, cipher suites, tecnologías, awareness, TPSP e IR según subcontrol aplicable (PCI DSS v4.0.1, Req 12.1.1, p. 290 LA; Req 12.10.2, p. 327 LA).
Trimestral [Solo SP]: revisión de ejecución de actividades operativas de seguridad (12.4.2) (PCI DSS v4.0.1, Req 12.4.2, p. 301 LA).
Semestral [Solo SP]: confirmación de scope (12.5.2.1) (PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA).
Periódicamente según TRA: entrenamiento de respuesta a incidentes (12.10.4) (PCI DSS v4.0.1, Req 12.10.4, p. 329 LA).

BAU vs evento puntual

Gobernanza, awareness, monitoreo de TPSP y mantenimiento de políticas son BAU. Cambio significativo, nuevo TPSP o uso de enfoque personalizado son eventos que exigen documentación y validación adicional.

Disparadores de Significant Change

Cambio significativo dispara confirmación de scope para todos (12.5.2) y para service provider con frecuencia adicional (12.5.2.1) (PCI DSS v4.0.1, Req 12.5.2, p. 304 LA; Req 12.5.2.1, p. 306 LA).
Nuevo TPSP o cambio de servicio exige mantener lista, acuerdos y monitoreo de cumplimiento (PCI DSS v4.0.1, Req 12.8.1, p. 317 LA; Req 12.8.4, p. 318 LA).
Control por enfoque personalizado exige TRA específica (12.3.2) (PCI DSS v4.0.1, Req 12.3.2, p. 297 LA).

Evidencia esperada y métodos de prueba

Subcontrol	Examinar	Observar	Entrevistar	Trampa de evidencia
12.3.1	TRA y revisión anual	—	Risk owner	Frecuencia “periódica” sin TRA
12.4.2	Revisiones trimestrales SP	Evidencia de tareas	Revisor independiente	Mismo operador revisa su tarea
12.5.2	Confirmación de scope	Inventario/flujos	Dueño scope	Assessor hace la confirmación
12.8.4	AOC/monitoreo TPSP	Portal/vendor file	Vendor manager	AOC reemplaza acuerdo escrito
12.10.2	Prueba IR anual	Ejercicio/tabletop	IR team	Revisar plan sin probarlo

Trampas frecuentes

Trampa: confundir TRA 12.3.1 con TRA 12.3.2. Por qué se cae: una justifica frecuencias “periódicamente”; la otra controles personalizados. Cómo distinguir: frecuencia vs alternativa de cumplimiento.
Trampa: creer que AOC del TPSP transfiere responsabilidad. Por qué se cae: la entidad conserva su propio cumplimiento. Cómo distinguir: validar matriz/acuerdos y monitoreo.
Trampa: asumir que el assessor confirma el scope por la entidad. Por qué se cae: la entidad confirma y documenta; el assessor valida. Cómo distinguir: buscar evidencia de actividad de la entidad.
Trampa: omitir [Solo SP] en 12.4.2 y 12.5.2.1. Por qué se cae: sujeto y frecuencia cambian. Cómo distinguir: merchant vs service provider.

Confusiones con otros requisitos

12.3.1 vs 12.3.2 → TRA de frecuencia periódica vs TRA de enfoque personalizado.
12.5.2 vs 12.5.2.1 → anual todos vs semestral [Solo SP].
12.8.2 vs 12.8.4 → reconocimiento escrito de responsabilidad vs monitoreo anual de cumplimiento.
12.10.2 vs 10.7.3 → prueba/revisión del plan IR vs respuesta documentada a falla de control.

Referencias cruzadas

high-risk-topics.md Temas 6 y 7.
reporting-and-testing.md sección TPSP.
periodicity-bau-significant-change.md filas 12.1.1 a 12.10.4.
Flashcards: FC-013, FC-056 a FC-075, FC-112 a FC-117.
mock-questions.md P-007, P-018, P-026, P-028 a P-033, P-050.
study-plan-7-days.md Días 4, 6 y 7.

Errores que cruzan múltiples requisitos

Confundir evidencia documental con operación real: política, procedimiento o estándar no prueba ejecución. Ver pci-isa-exam-guide.md.
Ignorar notas de aplicabilidad: varias respuestas correctas dependen del sujeto, fecha efectiva o condición de uso. Ver pci-isa-exam-guide.md.
Tratar “periódicamente” como frecuencia fija: requiere TRA conforme a 12.3.1. Ver high-risk-topics.md.
Mezclar frecuencia calendarizada con disparador por significant change: ambas obligaciones pueden coexistir. Ver periodicity-bau-significant-change.md.
Confundir controles internos, externos y de tercero: ASV, TPSP, assessor y personal interno cumplen roles distintos. Ver reporting-and-testing.md.
Omitir [Solo SP]: service provider tiene requisitos adicionales o frecuencias más exigentes. Ver recurring-activities-by-timeframe.md.
Creer que cifrado, segmentación o outsourcing eliminan automáticamente scope/responsabilidad. Ver pci-isa-exam-guide.md.
Validar diseño sin remediación: revisiones, scans y pruebas deben cerrar hallazgos según el requisito aplicable. Ver high-risk-topics.md.

Cómo seguir estudiando

Practica recall activo con flashcards.md, especialmente FC-047 a FC-120.
Usa mock-questions.md para validar distractores por periodicidad, evidencia y sujeto del requisito.
Repasa Examen_ISA_Extraido.md para reconocer formulaciones de examen y preguntas excluidas por alcance.
Sigue el orden de /guias/study-plan-7-days para cerrar brechas por día.