Guia Central del Examen ISA — PCI DSS v4.0.1

Este archivo es la guia de estudio orientada al examen ISA. Asume que los archivos periodicity-bau-significant-change.md y recurring-activities-by-timeframe.md ya fueron estudiados.

1. Mindset de Assessor

El examen ISA no evalua si sabes recitar los requisitos. Evalua si piensas como un assessor: alguien que determina si un control esta realmente en vigor, no solo documentado.

La distincion central del examen

Un assessor distingue siempre entre:

Nivel	Pregunta que hace el assessor
Politica documentada	”Existe la politica? Esta escrita?”
Control implementado	”Se esta haciendo operativamente lo que dice la politica?”
Evidencia de operacion	”Hay prueba de que el control funciono durante el periodo evaluado?”

Error critico de examen: confundir la existencia de una politica con la operacion del control. Una politica de revision de logs no prueba que los logs se revisaron. La evidencia de operacion — los registros de las revisiones, los tickets de seguimiento, los reportes — es lo que el assessor necesita.

Los tres tipos de actividad del assessor (PCI DSS v4.0.1, p. 31 LA)

Examinar: evaluacion critica de evidencia documental (documentos, capturas de pantalla, archivos de configuracion, registros de auditoria, archivos de datos).
Observar: el assessor presencia una accion o verifica algo en el entorno (personal ejecutando un proceso, un sistema respondiendo a un input, controles fisicos).
Entrevistar: conversacion con personal. El objetivo puede ser confirmar si una actividad se realiza, como se realiza, o si el personal tiene el conocimiento requerido.

Un control que solo puede evidenciarse mediante entrevista (sin documentos ni observacion) es debil. El examen pregunta sobre la solidez de la evidencia.

Principio del assessor ante la duda

Si una afirmacion no puede sustentarse en las fuentes oficiales — el PDF del estandar, FAQs del PCI SSC, o guia oficial — no se incluye en la evaluacion. Se declara explicitamente: “No documentado en PCI DSS v4.0.1 ni en FAQ oficial — verificar con QSA/PCI SSC.” (PCI DSS v4.0.1, p. 1 LA)

2. Determinacion del alcance: La Base de Todo

El alcance es la primera y mas importante decision de la evaluacion. Si el alcance esta mal definido, todo lo demas esta mal.

Definicion de CDE (PCI DSS v4.0.1, p. 9 LA)

El entorno de datos de tarjetahabiente comprende:

Componentes del sistema, personas y procesos que almacenan, procesan o transmiten CHD y/o SAD.
Componentes del sistema que no almacenan/procesan/transmiten CHD/SAD, pero tienen conectividad sin restricciones con los que si lo hacen.

Y tambien: 3. Componentes del sistema, personas y procesos que podrian impactar la seguridad de los datos de cuenta.

Las tres categorias de componentes del sistema en alcance

Categoria A (SPT):  Almacenan, Procesan o Transmiten CHD/SAD  → siempre en alcance
Categoria B (conectado a): Conectividad sin restricciones con Categoria A → en alcance
Categoria C (impacto en seguridad): Podrian impactar la seguridad del CDE → en alcance

Alta prioridad para examen: un sistema que NO toca CHD/SAD pero tiene conectividad sin restricciones con uno que si lo hace, ESTA en alcance. Ejemplos tipicos: servidores de autenticacion, servidores de acceso remoto, servidores de logging, servidores DNS, NTP, SIEM.

Segmentacion — lo que el estandar dice y lo que no

La segmentacion del CDE del resto de la red NO es un requisito PCI DSS — es una recomendacion fuertemente aconsejada. (PCI DSS v4.0.1, p. 12 LA)

Sin segmentacion adecuada: toda la red esta en alcance.

Para que un sistema este fuera de alcance, la segmentacion debe aislar ese sistema de forma que, incluso si fuera comprometido, no podria impactar la seguridad de CHD/SAD.

Alta prioridad para examen: el assessor debe verificar que la segmentacion es adecuada (Req 11.4.5 y 11.4.6). La presencia de reglas de firewall no garantiza segmentacion adecuada; las pruebas lo confirman.

Datos cifrados y alcance

El cifrado de CHD con criptografia fuerte es un metodo aceptable para hacer los datos ilegibles (Req 3.5). Pero el cifrado por si solo generalmente NO saca los datos del alcance. El entorno sigue en alcance si:

El sistema realiza cifrado/descifrado o gestion de claves.
Los datos cifrados no estan aislados de los procesos de cifrado/descifrado.
Los datos cifrados estan en el mismo entorno que la clave de descifrado.
Una entidad con acceso a los datos cifrados tambien tiene acceso a la clave.

(PCI DSS v4.0.1, p. 14 LA)

Roles dentro y fuera del alcance: lo que confunde

Escenario	Implicacion en alcance
Entidad que terceriza el procesamiento de pagos a un TPSP	Sigue siendo responsable de su propio cumplimiento PCI DSS
TPSP que recibe solo datos cifrados sin acceso a claves	Puede excluir esos datos del alcance (bajo ciertas condiciones)
TPSP que gestiona componentes en alcance en nombre del cliente	Esos requisitos aplican al cliente Y deben cubrirse por el TPSP
Usar un TPSP en cumplimiento PCI DSS	NO hace al cliente automaticamente cumplidor

3. Como Leer Preguntas del Examen ISA

Paso 1: Identificar que tipo de pregunta es

El examen ISA usa principalmente cuatro tipos:

Conceptual directa: “Cual es la frecuencia requerida para X?” → Busca la terminologia exacta del estandar.
Escenario de assessor: “Un assessor esta evaluando X. Que debe verificar?” → Piensa en examinar/observar/entrevistar y en evidencia de operacion.
Identificacion del mejor control: “Cual de las siguientes opciones cumple mejor el Req X?” → Busca la opcion que el estandar describe explicitamente, no la que parece logica.
Trampa de terminologia: “Cual es la diferencia entre X e Y?” → Alta precision terminologica requerida.

Paso 2: Identificar el sujeto exacto

Antes de responder, identifica:

¿A quienes aplica? (Todos / Solo SP / Solo DESV / Solo emisores)
¿Cual es el marco temporal exacto? (diario / semanalmente / cada tres meses / cada 12 meses / TRA / inmediatamente)
¿Cual es el trigger? (calendario / cambio significativo / evento especifico)
¿Enfoque definido o enfoque personalizado?

Paso 3: Descartar distractores sistematicamente

Los distractores en el examen ISA tipicamente:

Confunden frecuencias equivalentes pero usan terminologia diferente (“trimestral” vs. “cada tres meses” son equivalentes; “cada 12 meses” vs. “anualmente” son equivalentes).
Mezclan comerciante con proveedor de servicio (distintas frecuencias y requisitos adicionales).
Ofrecen controles documentados como si fueran controles operativos.
Proponen actividades razonables que NO estan en el estandar.
Confunden el enfoque definido con el enfoque personalizado.

Paso 4: Aplicar la regla de la fuente oficial

La respuesta correcta siempre puede rastrearse al texto del estandar, a una FAQ oficial, o a un Information Supplement oficial del PCI SSC. Si una opcion parece razonable pero no esta en ninguna fuente oficial, no es la respuesta correcta.

4. Como Pensar en Evidencia

La mentalidad del assessor ante cualquier requisito es: “¿Que necesito ver para confirmar que este control esta en vigor y operando efectivamente?”

Las tres preguntas de evidencia

Para cada requisito, el assessor busca:

Que: ¿Existe una politica, procedimiento o configuracion que define el control?
Como: ¿El control esta implementado correctamente en los sistemas/procesos?
Cuando: ¿Hay evidencia de que el control se ejecuto dentro del marco temporal requerido?

Tipos de evidencia por nivel de solidez

Nivel	Tipo	Ejemplo
Alto	Salida automatica de sistemas	Logs de sistema, reportes de escaneo, capturas de configuracion con timestamp
Medio	Registros operativos	Tickets de gestion de cambios, listas de revision firmadas, reportes de acceso
Bajo	Entrevistas sin documentacion de soporte	Personal dice “si lo hacemos” pero no hay registros

Alta prioridad: las entrevistas pueden confirmar el proceso, pero no son suficientes por si solas para validar que el control se ejecuto. El assessor siempre busca corroboracion documental o tecnica.

Evidencia de periodicidad: lo que el assessor verifica

Para cualquier actividad periodica (diaria, trimestral, anual), el assessor no solo verifica que existe el proceso — verifica que se ejecuto dentro del marco temporal requerido durante el periodo de la evaluacion.

Para escaneos trimestrales (Req 11.3.1, 11.3.2): el assessor examina los reportes de los ultimos 12 meses para confirmar que ocurrieron al menos 4 veces en intervalos que no excedan 90-92 dias.

Error comun: tener politica escrita pero no poder mostrar los registros de ejecucion. La politica + el registro de ejecucion + la evidencia de seguimiento de hallazgos son los tres elementos que el assessor necesita.

Evidencia en controles compensatorios

Los controles compensatorios deben documentarse anualmente y ser revisados y validados por el assessor. La documentacion del control compensatorio incluye: la razon por la que el requisito no puede cumplirse directamente, que riesgo adicional crea la desviacion, y como el control compensatorio mitiga ese riesgo de forma equivalente o superior. (PCI DSS v4.0.1, p. 28 LA)

5. Como Identificar Distractores

Patron 1: La frecuencia casi correcta

El estandar define frecuencias especificas. Los distractores usan variantes.

Lo que dice el requisito	Distractor tipico
al menos una vez cada tres meses (“trimestral”)	“al menos una vez por trimestre” ← equivalente, no es distractor; “al menos una vez cada dos meses” ← mas frecuente, no incumple; “al menos una vez cada cuatro meses” ← INCUMPLE
al menos una vez cada 12 meses (“anualmente”)	“al menos anualmente” ← equivalente; “al menos una vez cada 18 meses” ← INCUMPLE
inmediatamente	”within 24 hours” ← NO es “inmediatamente” segun el estandar
diario	”en dias habiles” ← INCUMPLE; “diario” = todos los dias del año

Patron 2: El requisito que aplica solo a SP presentado para todos

Muchos distractores presentan un requisito de proveedor de servicio como si aplicara a todos. Requisitos criticos solo para SP:

10.7.1: fallas de controles criticos (hasta marzo 2025)
12.4.2: revisiones operacionales trimestrales
12.5.2.1: confirmacion de alcance semestral
11.4.6: pruebas de segmentacion semestral
12.9.1 y 12.9.2: obligaciones de TPSP hacia sus clientes

Patron 3: La politica como sustituto del control

Opciones de respuesta que describen tener una politica escrita como cumplimiento de un requisito operativo. Ejemplo:

“Para cumplir el Req 10.4.1, la entidad debe: (A) tener una politica de revision de logs, (B) revisar diariamente los logs de seguridad y registrar los resultados.”

La respuesta correcta es B. Una politica sin evidencia de ejecucion no cumple el requisito.

Patron 4: El enfoque personalizado como excusa

El enfoque personalizado no es una forma de evitar controles — es una forma alternativa de demostrar que el objetivo de seguridad se cumple con controles distintos. Requiere TRA documentada (Req 12.3.2), controles que demuestren igual o mayor seguridad, y pruebas derivado por el assessor. No todos los requisitos admiten enfoque personalizado.

Patron 5: Mezclar “cambio significativo” con calendario

Algunos requisitos aplican TANTO por calendario COMO por cambio significativo. El distractor presenta solo uno de los dos:

Correcto: “al menos anualmente Y tras cambio significativo” (Req 11.4.2/11.4.3)
Distractor: “solo cuando hay cambios significativos” ← incompleto; falta el ciclo anual obligatorio

Patron 6: El TPSP que “resuelve” el cumplimiento del cliente

El uso de un TPSP en cumplimiento PCI DSS NO exime al cliente de su propio cumplimiento. El cliente sigue siendo responsable de: confirmar el alcance cubierto por el TPSP, monitorear el estado de cumplimiento del TPSP (Req 12.8.4), y cubrir los requisitos no gestionados por el TPSP.

6. Temas de Mayor Sensibilidad en el Examen

6.1 Determinacion del alcance y CDE

Conceptos mas preguntados:

Definicion exacta del CDE (SPT + conectado a con conectividad sin restricciones + impacto en seguridad).
“Conectado a” vs. fuera del alcance: la restriccion de la conectividad (segmentacion) es lo que saca a un sistema del alcance.
La segmentacion no es requerida; si se usa, debe verificarse mediante pruebas.
La confirmacion de alcance es responsabilidad de la entidad (no del assessor). El assessor valida que la confirmacion ocurrio y fue adecuada.

Requisitos clave:

12.5.2: confirmacion del alcance anual (todos)
12.5.2.1: confirmacion del alcance semestral (SP)
A3.2.1: confirmacion del alcance trimestral (DESV)
11.4.5 y 11.4.6: pruebas de segmentacion

6.2 Periodicidad y BAU

Ver periodicity-bau-significant-change.md y recurring-activities-by-timeframe.md para la tabla completa. Resumen de las trampas mas frecuentes:

Alta prioridad para examen — diferencias criticas:

Actividad	Comerciante	Proveedor de servicio
Confirmacion del alcance	Anual (12.5.2)	Semestral (12.5.2.1)
Pruebas de segmentacion	Anual (11.4.5)	Semestral (11.4.6)
Revisiones operacionales de cumplimiento	No requerido	Trimestral (12.4.2)

Las frecuencias “periodicamente” no son opcionales: requieren TRA documentada conforme a Req 12.3.1. Sin TRA, no se puede justificar la frecuencia elegida.

BAU vs. cumplimiento periodico: BAU significa que el control opera como parte del negocio normal, no solo cuando hay una evaluacion. El examen puede preguntar si una actividad es BAU o una evaluacion puntual.

6.3 Analisis de riesgo especificos (TRA)

Que es: un analisis de riesgo especifico para cada requisito PCI DSS que el estandar permite parametrizar. Distinto de una evaluacion de riesgo empresarial general.

Cuando se requiere: para todos los requisitos que dicen “periodicamente” sin especificar frecuencia fija.

Que debe incluir (Req 12.3.1, p. 295 LA):

Identificacion de los activos protegidos.
Identificacion de las amenazas de las que se protegen.
Controles implementados para proteger contra las amenazas.
Probabilidad de que la amenaza se realice.
Resultado: la frecuencia definida como apropiada para el negocio y el riesgo.
Revision al menos anual para determinar si los resultados siguen siendo validos.

Alta prioridad para examen:

La TRA define la frecuencia; no la justifica retroactivamente.
Si la TRA no existe o no cubre el requisito especifico, el requisito no esta en cumplimiento aunque la actividad se haya realizado.
La TRA de 12.3.2 (enfoque personalizado) es mas detallada y distinta de la TRA de 12.3.1.

6.4 Enfoque definido vs. enfoque personalizado

Enfoque definido (PCI DSS v4.0.1, p. 28 LA): sigue los requisitos tal como estan escritos. El assessor sigue los procedimientos de prueba definidos. Admite controles compensatorios (cuando hay restriccion tecnica o de negocio documentada y legitima). Los controles compensatorios deben documentarse y validarse anualmente.

Enfoque personalizado (PCI DSS v4.0.1, p. 28-29 LA): el objetivo del requisito se cumple con controles distintos a los descritos. No hay procedimientos de prueba definidos; el assessor los deriva. Requiere TRA documentada (12.3.2). Solo para entidades con madurez en gestion de riesgos. Algunos requisitos NO admiten enfoque personalizado (no tienen “Objetivo del Enfoque Personalizado”).

Alta prioridad para examen:

Enfoque personalizado no significa “hacer algo diferente sin justificacion”. Requiere rigor documental mayor que el enfoque definido.
La entidad puede usar ambos enfoques en distintos requisitos o distintos sistemas.
El control compensatorio es parte del enfoque definido, no del enfoque personalizado.

6.5 SAD vs. CHD: la distincion que importa

datos del titular de la tarjeta (CHD):

PAN (el unico elemento que por si solo activa PCI DSS)
Cardholder Name (solo si esta con el PAN)
Service Code (solo si esta con el PAN)
Expiration Date (solo si esta con el PAN)

datos de autenticacion sensibles (SAD):

Datos de pista completos (banda magnetica o equivalente en chip)
Card verification code (CVV2, CVC2, CID, etc.)
PINs / PIN blocks

Alta prioridad para examen — regla del SAD:

SAD nunca puede almacenarse despues de la autorizacion, incluso si esta cifrado.
Esta prohibicion aplica incluso si no hay PAN en el entorno.
Excepcion: emisores e entidades que apoyan servicios de emision (Req 3.3.3), con controles estrictos.

La regla del PAN: si se almacena PAN con otros elementos de CHD, solo el PAN debe hacerse ilegible. Los demas elementos de CHD (nombre, fecha de vencimiento, codigo de servicio) no requieren hacerse ilegibles, pero deben protegerse si estan en el mismo entorno que el PAN.

6.6 Evidencia, Procedimientos de prueba y Notas de aplicabilidad

Notas de aplicabilidad: indican cuando un requisito tiene alcance reducido o condiciones especiales. El examen pregunta sobre estas condiciones.

Ejemplos criticos:

Req 8.3.9: aplica SOLO cuando la contrasena es el unico factor de autenticacion. Con MFA, no aplica de la misma forma.
Req 5.3.2: el escaneo periodico de malware aplica SOLO si la entidad no usa monitoreo continuo.
Req 11.4.5: aplica SOLO si la entidad usa segmentacion. Si no usa segmentacion, no hay nada que testear.
Req 11.6.1: activo a partir del 31 de marzo de 2025 — antes era best practice.
Req 10.7.1 (solo SP): supersedido por 10.7.2 (todos) a partir del 31 de marzo de 2025.

Practicas recomendadas hasta 31 de marzo de 2025: varios requisitos de v4.0.1 eran practicas recomendadas hasta esa fecha y desde entonces son obligatorios. El examen los trata como obligatorios si la fecha de la evaluacion es posterior.

6.7 Requisitos de Alta Frecuencia de Error en Examen

Req 3.x — Proteccion de datos almacenados:

3.2.1: la entidad debe tener un proceso que se ejecute al menos trimestralmente para verificar y eliminar datos que superan el periodo de retencion. No basta con tener una politica de retencion.
3.3.1: SAD no puede almacenarse despues de la autorizacion, incluso cifrado.
3.4.1 y 3.5.1: diferencia entre truncar, tokenizar, hash unidireccional, cifrar. Solo los metodos listados en 3.5.1 hacen al PAN “ilegible” para PCI DSS.

Req 6.x — Desarrollo seguro:

6.4.1: dos opciones exclusivas (evaluacion anual por especialista en seguridad de aplicaciones O solucion automatizada continua). No pueden combinarse parcialmente.
6.5.2: todos los requisitos PCI DSS aplicables deben confirmarse al completar un cambio significativo. El cambio no esta “cerrado” hasta que se verifico el impacto en PCI DSS.

Req 8.x — Autenticacion:

8.2.5: revocacion de acceso al terminar la relacion — “inmediatamente”, no “within 24 hours”.
8.3.9: solo aplica cuando la contrasena es el unico factor. Trampa clasica: presentar como si aplicara a cuentas con MFA.
8.6.3: contrasenas de cuentas de aplicacion y sistema — frecuencia por TRA, no 90 dias fijo. Ademas, se cambian inmediatamente ante sospecha de compromiso.

Req 10.x — Logging:

10.4.1 vs. 10.4.2: logs criticos = diario (fijo); otros logs = periodico (TRA). Alta precision en la clasificacion de componentes.
10.5.1: retencion de 12 meses + 3 meses inmediatamente disponibles. “Inmediatamente disponible” no es lo mismo que “archivado con posibilidad de recuperacion”; debe poder accederse sin procesos lentos de restauracion.

Req 11.x — Pruebas de seguridad:

11.3.1 vs. 11.3.2: interno (no ASV) vs. externo (ASV obligatorio).
11.3.1.3 vs. 11.3.2.1: escaneos tras cambio significativo — ninguno requiere ASV (a diferencia del trimestral 11.3.2).
11.4.5 vs. 11.4.6: pruebas de segmentacion — anual para entidades que usan segmentacion, semestral para SP.
11.6.1: mecanismo en el navegador, no FIM tradicional. Evalua el contenido recibido por el consumidor.

Req 12.x — Politicas y gobernanza:

12.3.1: la revision anual de la TRA es obligatoria. No es suficiente hacer la actividad; la TRA debe existir y revisarse.
12.5.2 vs. 12.5.2.1: confirmacion del alcance — anual para todos, semestral para SP.
12.8.4: monitorear el estado de cumplimiento PCI DSS del TPSP no significa que el TPSP debe estar en cumplimiento PCI DSS; solo que el cliente monitorea su estado.
12.10.2: revision Y prueba del plan de IR — dos actividades distintas, ambas anuales.

7. Mapa de Dependencias para el Examen

Para responder correctamente, el examen ISA frecuentemente requiere conectar varios conceptos:

¿El sistema esta en alcance?
   └── ¿SPT o conectado a irrestricto o impacto en seguridad?
         └── SI → aplican todos los requisitos del estandar para ese componente
         └── NO → ¿hay segmentacion adecuada verificada? (11.4.5/11.4.6)

¿El requisito es periodico?
   └── ¿Hay frecuencia fija en el estandar?
         └── SI → ¿hay evidencia dentro del marco temporal?
         └── NO (dice "periodicamente") → ¿hay TRA documentada (12.3.1)?

¿El control esta en cumplimiento?
   └── ¿Politica/procedimiento documentado? (necesario pero no suficiente)
   └── ¿Control implementado correctamente? (configuracion, proceso)
   └── ¿Evidencia de operacion dentro del periodo requerido? (necesario)

¿La entidad es SP o comerciante?
   └── SP → requisitos adicionales: 12.4.2, 12.5.2.1, 11.4.6, 10.7.1 (hasta marzo 2025), 12.9.1, 12.9.2
   └── Comerciante → no aplican los requisitos adicionales solo para proveedores de servicio

8. Terminologia Exacta — Glosario Critico para el Examen

Usar la terminologia exacta del estandar evita errores de interpretacion.

Termino	Definicion segun PCI DSS v4.0.1
Datos de cuenta	Datos del titular de la tarjeta + datos de autenticacion sensibles
Datos del titular de la tarjeta (CHD)	PAN + nombre del titular + fecha de vencimiento + codigo de servicio (si estan con el PAN)
Datos de autenticacion sensibles (SAD)	Datos de pista completos + codigo de verificacion de tarjeta + PIN/bloques PIN
CDE	Entorno de datos de tarjetahabiente — el conjunto de componentes, personas y procesos que almacenan/procesan/transmiten CHD/SAD mas los que tienen conectividad sin restricciones con ellos
Componente del sistema	Dispositivos de red, servidores, dispositivos de computo, componentes virtuales, componentes cloud y software
Dentro del alcance	Dentro del CDE o que puede impactar la seguridad del CDE
Segmentacion	Aislamiento del CDE del resto de la red; no es requisito, pero si se usa debe verificarse
Cambio significativo	Ver definicion en periodicity-bau-significant-change.md (seis categorias de la p. 25-26 del PDF)
Analisis de riesgo especificos (TRA)	Analisis de riesgo especifico para requisitos con frecuencia “periodicamente”; distinto de la evaluacion de riesgo empresarial
Enfoque definido	Implementacion y validacion segun los requisitos y procedimientos de prueba tal como estan en el estandar
Enfoque personalizado	Implementacion alternativa que cumple el objetivo del requisito por otros medios; requiere TRA y pruebas derivado por el assessor
Control compensatorio	Control alternativo dentro del enfoque definido cuando hay restriccion tecnica o de negocio legitima; validado anualmente
Procedimiento de prueba	Las instrucciones especificas de como el assessor verifica el cumplimiento de un requisito (examinar/observar/entrevistar)
BAU	Procesos habituales — controles integrados en las operaciones diarias normales de seguridad, no solo ejecutados al momento de la evaluacion
Proveedor de servicio (SP)	Entidad de negocio que no es marca de pago, que provee servicios que involucran control sobre o influencia en la seguridad de CHD/SAD de otra entidad
TPSP	Proveedor de servicio externo — termino equivalente a SP en el contexto de relaciones con terceros
DESV	Validacion complementaria de entidades designadas — validacion adicional para entidades designadas (Apendice A3)
Notas de aplicabilidad	Notas en el texto del requisito que definen condiciones de alcance reducido o especial

9. Los 10 Errores Mas Comunes del Examen ISA

Confundir politica documentada con control operativo. La politica prueba la intencion; el registro de ejecucion prueba el cumplimiento.
Ignorar que “periodico” requiere TRA. Si el requisito dice “periodicamente”, la entidad DEBE tener una TRA documentada (Req 12.3.1). Sin TRA, no hay cumplimiento.
Asumir que los requisitos aplican igual a comerciantes y proveedores de servicio. SP tienen frecuencias mas cortas y requisitos adicionales.
Confundir cambio significativo con el ciclo periodico. Son dos triggers independientes. Tener el ciclo anual no exime de actuar tras un cambio significativo, y viceversa.
Asumir que el SAD puede almacenarse si esta cifrado. El SAD nunca puede almacenarse despues de la autorizacion, aunque este cifrado, aunque no haya PAN.
Confundir escaneos trimestrales internos (no ASV) con externos (ASV obligatorio). Req 11.3.1 ≠ Req 11.3.2.
Confundir “inmediatamente” con “within 24 hours”. Para revocacion de acceso al terminar la relacion (Req 8.2.5): “inmediatamente” no admite interpretacion de 24 horas.
Asumir que usar un TPSP en cumplimiento PCI DSS exime al cliente. El cliente mantiene su propia responsabilidad de cumplimiento.
Tratar el enfoque personalizado como una forma de relajar controles. Requiere mayor documentacion, TRA especifica, y pruebas derivadas por el assessor. No es un atajo.
Ignorar las Notas de aplicabilidad. Son parte del requisito. Req 8.3.9 solo aplica con autenticacion de factor unico; Req 11.4.5 solo aplica si se usa segmentacion; Req 5.3.2.1 solo si se usan escaneos periodicos en lugar de monitoreo continuo.

Fuentes consultadas

PCI DSS v4.0.1: Requisitos y Procedimientos de Prueba, version 4.0.1, junio 2024, PCI Security Standards Council. Fuente local: docs/es/PCI-DSS-v4_0_1-LA.pdf.
- Seccion “Aplicabilidad PCI DSS”, p. 4-8 LA.
- Seccion “Alcance de los Requisitos de PCI DSS”, p. 9-16 LA.
- Seccion “Descripcion de los Plazos Utilizados en los Requisitos de PCI DSS”, p. 25-27 LA.
- Seccion “Mejores Practicas para la Implementacion PCI DSS en Procesos Habituales”, p. 19-21 LA.
- Seccion “Enfoques para Implementar y Validar PCI DSS”, p. 28-30 LA.
- Seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA.
- Requisitos 3.2.1, 3.3.1, 3.5.1, 6.4.1, 6.5.2, 8.2.5, 8.3.9, 8.6.3, 10.4.1, 10.4.2, 10.5.1, 11.3.1, 11.3.2, 11.4.1-11.4.6, 11.6.1, 12.3.1, 12.3.2, 12.4.2, 12.5.2, 12.5.2.1, 12.8.4, 12.10.2.
Archivos de este proyecto:
- periodicity-bau-significant-change.md — base canonica de requisitos recurrentes.
- recurring-activities-by-timeframe.md — vista por marco temporal.
Links de referencia PCI SSC: docs/links-pci.txt.