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 assessor antes del examen. No reemplaza el estandar: organiza el repaso con foco en evidencia, scope, periodicidad, BAU, significant change, targeted risk analysis 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 assessor

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 assessor: no basta con que exista una politica; debe existir evidencia de diseno y operacion.
  • Testing methods: examine, observe e interview (PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31).
  • Defined approach vs customized approach: el customized approach requiere controles alternativos, objetivo de seguridad cumplido y testing definido por el assessor; no es una excepcion informal (PCI DSS v4.0.1, seccion “Approaches for Implementing and Validating PCI DSS”, p. 28-30).
  • 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 assessor.
  • Para cada ejemplo, separa “control documentado” de “control operativo”.
  • Reescribe tres afirmaciones debiles como conclusiones de assessor 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 customized approach 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).

Dia 2 — Scope, CDE y segmentacion

Objetivo

Dominar el criterio de scope: que entra en el assessment, como se tratan connected-to systems y como validar segmentacion sin asumir que siempre existe.

Temas

  • CDE, system components in scope y connected-to systems (PCI DSS v4.0.1, seccion “Scope of PCI DSS Requirements”, p. 9-16).
  • CHD vs SAD y restricciones de almacenamiento (PCI DSS v4.0.1, Table 2 y Table 3, p. 4-6).
  • Segmentacion: no es obligatoria, pero si se usa para reducir scope debe probarse.
  • Confirmacion de scope por la entidad al menos cada 12 meses y ante significant change (PCI DSS v4.0.1, Req 12.5.2, p. 304-306).
  • Para service providers, confirmacion de scope al menos cada seis meses y ante significant change (PCI DSS v4.0.1, Req 12.5.2.1, p. 306).

Tiempo sugerido

2 a 3 horas.

Lecturas base

Ejercicios

  • Dibuja un mini-scope con CDE, sistemas conectados, un tercero y un segmento out of scope.
  • Marca que evidencia pedirias para sostener que la segmentacion reduce scope.
  • 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 en scope aunque no almacenen CHD?
  • Si una entidad no usa segmentacion, aplica el testing de segmentacion?
  • Que cambia entre merchant y service provider para scope confirmation?

Puntos de atencion para el examen

  • Alta prioridad: segmentacion no es requisito universal; el testing se vuelve critico si se usa para reducir scope.
  • Error comun: confundir la confirmacion anual de scope hecha por la entidad con la validacion de scope que realiza el assessor durante el assessment.

Dia 3 — Periodicidad, BAU y significant change

Objetivo

Memorizar los marcos temporales mas preguntables y distinguir frecuencia fija, TRA y actividades event-driven.

Temas

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

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 significant change y explica por que no reemplazan el ciclo periodico.
  • Clasifica diez controles como frecuencia fija, TRA o event-driven.

Preguntas de autoevaluacion

  • “Periodically” 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: “periodically” requiere frecuencia definida por la entidad mediante targeted risk analysis cuando el requisito lo especifica (PCI DSS v4.0.1, Req 12.3.1, p. 295-297).
  • Error comun: creer que ejecutar una actividad tras significant change elimina la obligacion anual, trimestral o semestral.

Dia 4 — TRA, service providers y DESV

Objetivo

Entender cuando una frecuencia depende de targeted risk analysis, que debe contener esa TRA y como cambian las obligaciones para service providers y designated entities.

Temas

  • Req 12.3.1: TRA para requisitos que especifican targeted risk analysis; 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).
  • Diferencia entre TRA de 12.3.1 y TRA de customized approach en 12.3.2 (PCI DSS v4.0.1, Req 12.3.2, p. 297).
  • 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.
  • Service providers: 12.4.2, 12.5.2.1, A1.1.4 y diferencias de frecuencia en segmentacion y scope.
  • 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 targeted exigida por 12.3.1.

Preguntas de autoevaluacion

  • Que elementos minimos debe incluir una TRA de 12.3.1?
  • Que diferencia hay entre service provider y merchant 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 applicability notes y errores tipicos.

Temas

  • Req 3: retencion y eliminacion trimestral de account data que excede el periodo definido (PCI DSS v4.0.1, Req 3.2.1, p. 76).
  • 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; Req 6.5.1, p. 155; Req 6.5.2, p. 156).
  • 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; Req 6.4.2, p. 151-152).
  • 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; Req 7.2.5.1, p. 169; Req 8.2.5, p. 181; Req 8.2.6, p. 182; Req 8.3.9, p. 192).

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 account data mas alla de su retencion definida?
  • Que significa “immediately” 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 significant change; no basta con aprobar el cambio tecnico.
  • Error comun: aplicar 8.3.9 a escenarios con MFA sin leer la applicability note.

Dia 6 — Requisitos 10, 11 y 12

Objetivo

Dominar logging, respuesta a fallas de controles criticos, scans, penetration testing, 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; Req 10.4.2, p. 248; Req 10.5.1, p. 251).
  • 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; Req 10.7.3, p. 257).
  • Req 11: wireless rogue AP detection, internal/external vulnerability scans, ASV, authenticated scans, post-change scans, pen testing y segmentation testing.
  • 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).
  • Req 12: politica anual, TRA, tecnologias, TPSP, scope confirmation, awareness e incident response (PCI DSS v4.0.1, Req 12.1.1, p. 290; Req 12.8.4, p. 318; Req 12.10.2, p. 327).

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 scan externo trimestral requiere ASV, pero el post-significant-change externo no lo requiere (PCI DSS v4.0.1, Req 11.3.2, p. 270; Req 11.3.2.1, p. 272).
  • 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 assessor 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/change-detection 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 scope, evidencia, periodicidad, BAU, significant change, TRA, SP/DESV y requisitos de alta confusion.
  • Lectura de preguntas por sujeto, trigger, evidencia y applicability.
  • Matriz de errores comunes: politica vs operacion, periodic vs annual, merchant vs SP, TRA vs customized approach, significant change 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 significant change.

Preguntas de autoevaluacion

  • Puedo explicar en menos de un minuto la diferencia entre BAU, significant change 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, trigger 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 event-driven.
  • Puedo reconocer requisitos solo service provider y requisitos DESV.
  • Puedo explicar que significant change no reemplaza el calendario.
  • Puedo distinguir scan interno, scan externo ASV, scan post-change y pen test.
  • Puedo explicar la diferencia entre Req 12.3.1 y Req 12.3.2.
  • Puedo identificar applicability notes 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