Corpus de estudio

Plan de estudio 7 días | ISA PCI DSS v4.0.1

Plan

Plan de estudio 7 días

Plan de estudio de 7 dias — ISA PCI DSS v4.0.1

Este plan esta pensado para alguien que ya realizo el curso ISA y necesita consolidar criterio de evaluador antes del examen. No reemplaza el estandar: organiza el repaso con foco en evidencia, determinación del alcance, periodicidad, BAU, cambio significativo, análisis de riesgo específicos y distractores frecuentes.

Tiempo sugerido base: 2 a 3 horas por dia. Si tienes menos tiempo, prioriza las lecturas base y las preguntas de autoevaluacion; si tienes mas tiempo, rehace los ejercicios con ejemplos propios.

Dia 1 — Pensar como evaluador

Objetivo

Consolidar el marco mental del examen: que significa evaluar cumplimiento, como se lee una pregunta ISA y que tipo de evidencia soporta una conclusion.

Temas

  • Mindset de evaluador: no basta con que exista una politica; debe existir evidencia de diseno y operacion.
  • Métodos de prueba: examinar, observar y entrevistar (PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 LA).
  • Enfoque definido vs enfoque personalizado: el enfoque personalizado requiere controles alternativos, objetivo de seguridad cumplido y pruebas definidas por el evaluador; no es una excepcion informal (PCI DSS v4.0.1, seccion “Approaches for Implementing and Validating PCI DSS”, p. 28-30 LA).
  • Como detectar distractores: frecuencia casi correcta, sujeto incorrecto, evidencia insuficiente, requisito solo SP presentado como general.

Tiempo sugerido

2 horas.

Lecturas base

Ejercicios

  • Toma cinco requisitos de cualquier archivo base y escribe que evidencia documental, entrevista y observacion pediria un evaluador.
  • Para cada ejemplo, separa “control documentado” de “control operativo”.
  • Reescribe tres afirmaciones debiles como conclusiones de evaluador basadas en evidencia.

Preguntas de autoevaluacion

  • Que diferencia hay entre una politica aprobada y evidencia de operacion recurrente?
  • Cuando una pregunta ofrece una respuesta “mas segura” pero no alineada al requisito, que deberia elegir el ISA?
  • Por que interview por si sola rara vez es suficiente para cerrar evidencia?

Puntos de atencion para el examen

  • Alta prioridad: los distractores suelen reemplazar evidencia operativa por politicas.
  • Error comun: asumir que enfoque personalizado permite omitir el requisito. Debe demostrarse el objetivo de seguridad y documentarse la TRA aplicable (PCI DSS v4.0.1, Req 12.3.2, p. 297 LA).

Dia 2 — Scope, CDE y segmentacion

Objetivo

Dominar el criterio de determinación del alcance: que entra en el evaluación, como se tratan sistemas “conectado a” y como validar segmentacion sin asumir que siempre existe.

Temas

  • CDE, componentes del sistema dentro del alcance y sistemas “conectado a” (PCI DSS v4.0.1, seccion “Scope of PCI DSS Requirements”, p. 9-16 LA).
  • CHD vs SAD y restricciones de almacenamiento (PCI DSS v4.0.1, Table 2 y Table 3, p. 4-6 LA).
  • Segmentacion: no es obligatoria, pero si se usa para reducir el alcance debe probarse.
  • Confirmacion de determinación del alcance por la entidad al menos cada 12 meses y ante cambio significativo (PCI DSS v4.0.1, Req 12.5.2, p. 304-306 LA).
  • Para proveedores de servicio, confirmacion de determinación del alcance al menos cada seis meses y ante cambio significativo (PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA).

Tiempo sugerido

2 a 3 horas.

Lecturas base

Ejercicios

  • Dibuja un mini mapa de alcance con CDE, sistemas conectados, un tercero y un segmento fuera del alcance.
  • Marca que evidencia pedirias para sostener que la segmentacion reduce determinación del alcance.
  • Compara 11.4.5, 11.4.6, 12.5.2 y 12.5.2.1 en una tabla de una pagina.

Preguntas de autoevaluacion

  • Que tipos de sistemas entran dentro del alcance aunque no almacenen CHD?
  • Si una entidad no usa segmentacion, aplica el testing de segmentacion?
  • Que cambia entre comerciante y proveedor de servicio para confirmación de la determinación del alcance?

Puntos de atencion para el examen

  • Alta prioridad: segmentacion no es requisito universal; el testing se vuelve critico si se usa para reducir el alcance.
  • Error comun: confundir la confirmacion anual de determinación del alcance hecha por la entidad con la validacion de determinación del alcance que realiza el evaluador durante el evaluación.

Dia 3 — Periodicidad, BAU y cambio significativo

Objetivo

Memorizar los marcos temporales mas preguntables y distinguir frecuencia fija, TRA y actividades orientado por evento.

Temas

  • Description of Timeframes Used in PCI DSS Requirements (PCI DSS v4.0.1, p. 25-27 LA).
  • BAU como integracion de controles en la operacion normal, no como actividad solo de evaluación (PCI DSS v4.0.1, seccion BAU, p. 19-21 LA).
  • Cambio significativo: disparador independiente del calendario (PCI DSS v4.0.1, seccion “Timeframes in PCI DSS Requirements”, p. 25-26 LA).
  • Frecuencias criticas: diario, semanal, trimestral, semestral, anual, cada 90 dias, inmediato y con prontitud.
  • Requisitos con doble disparador: calendario y cambio significativo.

Tiempo sugerido

3 horas.

Lecturas base

Ejercicios

  • Escribe de memoria una lista de requisitos diarios, trimestrales, semestrales y anuales; luego valida contra recurring-activities-by-timeframe.md.
  • Identifica cinco requisitos que se disparan por cambio significativo y explica por que no reemplazan el ciclo periodico.
  • Clasifica diez controles como frecuencia fija, TRA o actividad orientada por evento.

Preguntas de autoevaluacion

  • “Periódicamente” significa anual?
  • Que evidencia demuestra que una actividad BAU se realizo durante el periodo evaluado?
  • Que diferencia hay entre “every 90 days” y “every three months” para el examen?

Puntos de atencion para el examen

  • Alta prioridad: “periódicamente” requiere frecuencia definida por la entidad mediante análisis de riesgo específicos cuando el requisito lo especifica (PCI DSS v4.0.1, Req 12.3.1, p. 295-297 LA).
  • Error comun: creer que ejecutar una actividad tras cambio significativo elimina la obligacion anual, trimestral o semestral.

Dia 4 — TRA, proveedores de servicio y DESV

Objetivo

Entender cuando una frecuencia depende de análisis de riesgo específicos, que debe contener esa TRA y como cambian las obligaciones para proveedores de servicio y designated entities.

Temas

  • Req 12.3.1: TRA para requisitos que especifican análisis de riesgo específicos; debe incluir activos protegidos, amenazas, factores de probabilidad e impacto, controles y revision al menos cada 12 meses (PCI DSS v4.0.1, Req 12.3.1, p. 295-297 LA).
  • Diferencia entre TRA de 12.3.1 y TRA de enfoque personalizado en 12.3.2 (PCI DSS v4.0.1, Req 12.3.2, p. 297 LA).
  • Requisitos con frecuencia definida por TRA: 5.2.3, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2, 11.3.1.1, 11.6.1 y 12.10.4.1.
  • Proveedores de servicio: 12.4.2, 12.5.2.1, A1.1.4 y diferencias de frecuencia en segmentacion y determinación del alcance.
  • DESV: requisitos A3 con ciclos adicionales, especialmente A3.2.1, A3.2.5 y A3.3.3.

Tiempo sugerido

2 a 3 horas.

Lecturas base

Ejercicios

  • Construye una mini-TRA para 10.4.2: activo protegido, amenaza, impacto, probabilidad, frecuencia y justificacion.
  • Marca en una lista todos los requisitos solo SP de los archivos base.
  • Explica en cinco lineas por que una TRA empresarial general no reemplaza la TRA específica exigida por 12.3.1.

Preguntas de autoevaluacion

  • Que elementos minimos debe incluir una TRA de 12.3.1?
  • Que diferencia hay entre proveedor de servicio y comerciante para 12.5.2?
  • Que requisitos DESV tienen ciclos mas exigentes que el requisito base?

Puntos de atencion para el examen

  • Alta prioridad: la ausencia de TRA documentada es incumplimiento aunque la actividad se haya hecho.
  • Error comun: mezclar Req 12.3.1 con Req 12.3.2. Tienen propositos distintos.

Dia 5 — Requisitos 3, 4, 6, 7 y 8

Objetivo

Repasar controles de datos, criptografia, desarrollo seguro, acceso y autenticacion con foco en notas de aplicabilidad y errores tipicos.

Temas

  • Req 3: retencion y eliminacion trimestral de datos de cuenta que excede el periodo definido (PCI DSS v4.0.1, Req 3.2.1, p. 76 LA).
  • Req 4: proteccion de CHD en transmision con criptografia fuerte; reforzar diferencias entre almacenamiento y transmision.
  • Req 6: desarrollo seguro, revision de codigo antes de release y change management (PCI DSS v4.0.1, Req 6.2.3, p. 138 LA; Req 6.5.1, p. 155 LA; Req 6.5.2, p. 156 LA).
  • Req 6.4.1 vs 6.4.2: desde el 31 de marzo de 2025, 6.4.2 reemplaza la opcion manual de 6.4.1 para aplicaciones web publicas (PCI DSS v4.0.1, Req 6.4.1, p. 150-151 LA; Req 6.4.2, p. 151-152 LA).
  • Req 7 y 8: revision semestral de accesos de usuario, cuentas de aplicacion/sistema por TRA, revocacion inmediata, cuentas inactivas y contrasenas single-factor (PCI DSS v4.0.1, Req 7.2.4, p. 167 LA; Req 7.2.5.1, p. 169 LA; Req 8.2.5, p. 181 LA; Req 8.2.6, p. 182 LA; Req 8.3.9, p. 192 LA).

Tiempo sugerido

3 horas.

Lecturas base

Ejercicios

  • Comparar 6.4.1 y 6.4.2 en una tabla de “antes/despues del 31/03/2025”.
  • Escribir tres escenarios de cambio y decidir si activan 6.5.2.
  • Separar controles de usuario humano y cuentas de aplicacion/sistema en Req 7 y 8.

Preguntas de autoevaluacion

  • Que evidencia demuestra que la entidad no conserva datos de cuenta mas alla de su retencion definida?
  • Que significa “inmediatamente” en revocacion de acceso?
  • Cuando aplica el cambio de contrasena cada 90 dias de 8.3.9?

Puntos de atencion para el examen

  • Alta prioridad: Req 6.5.2 exige confirmar todos los requisitos PCI DSS aplicables tras cambio significativo; no basta con aprobar el cambio tecnico.
  • Error comun: aplicar 8.3.9 a escenarios con MFA sin leer la nota de aplicabilidad.

Dia 6 — Requisitos 10, 11 y 12

Objetivo

Dominar logging, respuesta a fallas de controles criticos, escaneos, pruebas de penetración, tamper detection, politicas, terceros e incident response.

Temas

  • Req 10: revision diaria de logs criticos, revision por TRA de otros logs, retencion de 12 meses y 3 meses inmediatamente disponibles (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA; Req 10.4.2, p. 248 LA; Req 10.5.1, p. 251 LA).
  • Req 10.7.2 y 10.7.3: deteccion, alerta, respuesta y documentacion de fallas de sistemas de control de seguridad criticos (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA; Req 10.7.3, p. 257 LA).
  • Req 11: wireless rogue AP detection, internal/external vulnerability escaneos, ASV, authenticated escaneos, post-change escaneos, prueba de penetracióning y prueba de segmentación.
  • Req 11.6.1: deteccion de cambios en paginas de pago al menos semanalmente o por TRA (PCI DSS v4.0.1, Req 11.6.1, p. 287-288 LA).
  • Req 12: politica anual, TRA, tecnologias, TPSP, confirmación de la determinación del alcance, awareness e incident response (PCI DSS v4.0.1, Req 12.1.1, p. 290 LA; Req 12.8.4, p. 318 LA; Req 12.10.2, p. 327 LA).

Tiempo sugerido

3 horas.

Lecturas base

Ejercicios

  • Hacer una tabla comparativa de 11.3.1, 11.3.1.2, 11.3.1.3, 11.3.2 y 11.3.2.1.
  • Explicar por que el escaneo externo trimestral requiere ASV, pero el post-cambio significativo externo no lo requiere (PCI DSS v4.0.1, Req 11.3.2, p. 270 LA; Req 11.3.2.1, p. 272 LA).
  • Crear tres ejemplos de evidencia para 12.8.4, 12.10.2 y 10.7.3.

Preguntas de autoevaluacion

  • Que logs se revisan diariamente y cuales pueden revisarse segun TRA?
  • Que diferencia hay entre scan de vulnerabilidades y penetration test?
  • Que evidencia esperaria el evaluador para un plan de incident response probado?

Puntos de atencion para el examen

  • Alta prioridad: 11.3.1 interno no requiere ASV; 11.3.2 externo trimestral si requiere ASV.
  • Error comun: confundir FIM/detección de cambios general con el mecanismo especifico de 11.6.1 para paginas de pago.

Dia 7 — Repaso integrado y simulacion personal

Objetivo

Cerrar brechas, practicar lectura de preguntas y consolidar una matriz mental de errores comunes antes del examen.

Temas

  • Repaso completo de determinación del alcance, evidencia, periodicidad, BAU, cambio significativo, TRA, SP/DESV y requisitos de alta confusion.
  • Lectura de preguntas por sujeto, disparador, evidencia y aplicabilidad.
  • Matriz de errores comunes: politica vs operacion, periodic vs annual, comerciante vs SP, TRA vs enfoque personalizado, cambio significativo vs calendario.

Tiempo sugerido

3 horas.

Lecturas base

Ejercicios

  • Crear 20 preguntas propias tipo examen con cuatro opciones y justificar por que tres son distractores.
  • Revisar todas las respuestas contra los archivos base; si una respuesta no tiene fuente clara, marcarla como “verificar con QSA/PCI SSC”.
  • Hacer un repaso cronometrado de frecuencias: diario, semanal, 90 dias, trimestral, semestral, anual, TRA y cambio significativo.

Preguntas de autoevaluacion

  • Puedo explicar en menos de un minuto la diferencia entre BAU, cambio significativo y TRA?
  • Puedo identificar rapidamente un requisito solo SP?
  • Puedo justificar cada respuesta con fuente oficial o archivo trazado?

Puntos de atencion para el examen

  • Alta prioridad: no respondas por intuicion operativa si el estandar usa un sujeto, disparador o frecuencia especifica.
  • Error comun: escoger la opcion mas amplia o madura cuando la pregunta pide la mejor respuesta segun PCI DSS.

Checklist final antes del examen

  • Puedo distinguir evidencia documental, entrevista y observacion.
  • Puedo explicar por que una politica no prueba operacion.
  • Puedo listar las frecuencias criticas sin mezclar “90 dias”, “three months”, “six months” y “12 months”.
  • Puedo separar frecuencia fija, TRA y actividad orientada por evento.
  • Puedo reconocer requisitos solo proveedor de servicio y requisitos DESV.
  • Puedo explicar que cambio significativo no reemplaza el calendario.
  • Puedo distinguir escaneo interno, escaneo externo ASV, scan post-change y prueba de penetración.
  • Puedo explicar la diferencia entre Req 12.3.1 y Req 12.3.2.
  • Puedo identificar notas de aplicabilidad que cambian la respuesta.
  • Puedo sustentar cada respuesta con PCI DSS v4.0.1 o con los archivos del corpus que ya contienen trazabilidad.

Fuentes consultadas