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)

Examine: evaluacion critica de evidencia documental (documentos, capturas de pantalla, archivos de configuracion, audit logs, archivos de datos).
Observe: el assessor presencia una accion o verifica algo en el entorno (personal ejecutando un proceso, un sistema respondiendo a un input, controles fisicos).
Interview: 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 interview (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 guidance oficial — no se incluye en el assessment. 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)

2. Scoping: La Base de Todo

El scope es la primera y mas importante decision del assessment. Si el scope esta mal definido, todo lo demas esta mal.

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

El Cardholder Data Environment 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 irrestricta 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 system components en scope

Categoria A (SPT):  Almacenan, Procesan o Transmiten CHD/SAD  → siempre en scope
Categoria B (connected-to): Conectividad irrestricta con Categoria A → en scope
Categoria C (security impact): Podrian impactar la seguridad del CDE → en scope

Alta prioridad para examen: un sistema que NO toca CHD/SAD pero tiene conectividad irrestricta con uno que si lo hace, ESTA en scope. 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)

Sin segmentacion adecuada (“flat network”): toda la red esta en scope.

Para que un sistema este fuera de scope, 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; el testing lo confirma.

Datos cifrados y scope

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 scope. El entorno sigue en scope 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)

Roles en scope vs. out of scope: lo que confunde

Escenario	Implicacion en scope
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 scope (bajo ciertas condiciones)
TPSP que gestiona componentes en scope en nombre del cliente	Esos requisitos aplican al cliente Y deben cubrirse por el TPSP
Usar un TPSP PCI DSS compliant	NO hace al cliente automaticamente compliant

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 examine/observe/interview 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? (daily / weekly / every three months / every 12 months / TRA / immediately)
¿Cual es el trigger? (calendario / significant change / evento especifico)
¿Defined approach o customized approach?

Paso 3: Descartar distractores sistematicamente

Los distractores en el examen ISA tipicamente:

Confunden frecuencias equivalentes pero usan terminologia diferente (“quarterly” vs. “every three months” — son iguales; “every 12 months” vs. “annually” — son iguales).
Mezclan merchant con service provider (distintas frecuencias y requisitos adicionales).
Ofrecen controles documentados como si fueran controles operativos.
Proponen actividades razonables que NO estan en el estandar.
Confunden el defined approach con el customized approach.

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 change management, listas de revision firmadas, reportes de acceso
Bajo	Entrevistas sin documentacion de soporte	Personal dice “si lo hacemos” pero no hay registros

Alta prioridad: los interviews pueden confirmar el proceso, pero no son suficientes por si solos 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 del assessment.

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 compensating controls

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

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
at least once every three months	”at least once every quarter” ← equivalente, no es distractor; “at least once every two months” ← mas frecuente, no incumple; “at least once every four months” ← INCUMPLE
at least once every 12 months	”at least annually” ← equivalente; “at least once every 18 months” ← INCUMPLE
immediately	”within 24 hours” ← NO es “immediately” segun el estandar
daily	”on business days” ← INCUMPLE; “daily” = todos los dias del año

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

Muchos distractores presentan un requisito de service provider 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 scope semestral
11.4.6: segmentation testing 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 customized approach como excusa

El customized approach 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 testing derivado por el assessor. No todos los requisitos admiten customized approach.

Patron 5: Mezclar “significant change” con calendar

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

Correcto: “al menos anualmente Y tras significant change” (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 PCI DSS compliant NO exime al cliente de su propio cumplimiento. El cliente sigue siendo responsable de: confirmar el scope 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 Scoping y CDE

Conceptos mas preguntados:

Definicion exacta del CDE (SPT + connected-to irrestricto + security impact).
“Connected-to” vs. “out of scope”: la restriccion de la conectividad (segmentacion) es lo que saca a un sistema del scope.
La segmentacion no es requerida; si se usa, debe verificarse mediante testing.
La confirmacion de scope es responsabilidad de la entidad (no del assessor). El assessor valida que la confirmacion ocurrio y fue adecuada.

Requisitos clave:

12.5.2: scope confirmation anual (todos)
12.5.2.1: scope confirmation semestral (SP)
A3.2.1: scope confirmation trimestral (DESV)
11.4.5 y 11.4.6: segmentation testing

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	Merchant	Service Provider
Scope confirmation	Anual (12.5.2)	Semestral (12.5.2.1)
Segmentation testing	Anual (11.4.5)	Semestral (11.4.6)
Operational compliance reviews	No requerido	Trimestral (12.4.2)

Las frecuencias “periodically” 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 un assessment. El examen puede preguntar si una actividad es BAU o una evaluacion puntual.

6.3 Targeted Risk Analysis (TRA)

Que es: un analisis de riesgo especifico para cada requisito PCI DSS que el estandar permite parametrizar. Distinto de un enterprise-wide risk assessment general.

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

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

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 (customized approach) es mas detallada y distinta de la TRA de 12.3.1.

6.4 Defined Approach vs. Customized Approach

Defined approach (PCI DSS v4.0.1, p. 28): sigue los requisitos tal como estan escritos. El assessor sigue los testing procedures definidos. Admite compensating controls (cuando hay restriccion tecnica o de negocio documentada y legitima). Los compensating controls deben documentarse y validarse anualmente.

Customized approach (PCI DSS v4.0.1, p. 28-29): el objetivo del requisito se cumple con controles distintos a los descritos. No hay testing procedures definidos; el assessor los deriva. Requiere TRA documentada (12.3.2). Solo para entidades con madurez en gestion de riesgos. Algunos requisitos NO admiten customized approach (no tienen “Customized Approach Objective”).

Alta prioridad para examen:

Customized approach no significa “hacer algo diferente sin justificacion”. Requiere rigor documental mayor que el defined approach.
La entidad puede usar ambos enfoques en distintos requisitos o distintos sistemas.
El compensating control es parte del defined approach, no del customized approach.

6.5 SAD vs. CHD: la distincion que importa

Cardholder Data (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)

Sensitive Authentication Data (SAD):

Full track data (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, Testing Procedures y Applicability Notes

Applicability Notes: 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 (single-factor). 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 (SP only): supersedido por 10.7.2 (todos) a partir del 31 de marzo de 2025.

Best practices hasta 31 de marzo de 2025: varios requisitos de v4.0.1 eran best practices hasta esa fecha y desde entonces son obligatorios. El examen los trata como obligatorios si la fecha del assessment 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 app security OR solucion automatizada continua). No pueden combinarse parcialmente.
6.5.2: todos los requisitos PCI DSS aplicables deben confirmarse al completar un significant change. 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 — “immediately”, 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. “Immediately available” no es lo mismo que “archivado con posibilidad de recuperacion”; debe poder accederse sin procesos lentos de restauracion.

Req 11.x — Testing 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 post-significant change — ninguno requiere ASV (a diferencia del trimestral 11.3.2).
11.4.5 vs. 11.4.6: segmentation testing — annual para entidades que usan segmentacion, semestral para SP.
11.6.1: mecanismo en el browser, 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: scope confirmation — anual para todos, semestral para SP.
12.8.4: monitorear el estado de cumplimiento PCI DSS del TPSP no significa que el TPSP debe ser PCI DSS compliant; 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 scope?
   └── ¿SPT o connected-to irrestricto o security impact?
         └── 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 "periodically") → ¿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 merchant?
   └── 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
   └── Merchant → no aplican los "additional requirements for service providers only"

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
Account data	Cardholder data + sensitive authentication data
Cardholder data (CHD)	PAN + cardholder name + expiration date + service code (si estan con el PAN)
Sensitive authentication data (SAD)	Full track data + card verification code + PINs/PIN blocks
CDE	Cardholder data environment — el conjunto de componentes, personas y procesos que almacenan/procesan/transmiten CHD/SAD mas los que tienen conectividad irrestricta con ellos
System component	Dispositivos de red, servidores, dispositivos de computo, componentes virtuales, componentes cloud y software
In scope	Dentro del CDE o que puede impactar la seguridad del CDE
Segmentation	Aislamiento del CDE del resto de la red; no es requisito, pero si se usa debe verificarse
Significant change	Ver definicion en periodicity-bau-significant-change.md (seis categorias de la p. 25-26 del PDF)
Targeted risk analysis (TRA)	Analisis de riesgo especifico para requisitos con frecuencia “periodically”; distinto del enterprise risk assessment
Defined approach	Implementacion y validacion segun los requisitos y testing procedures tal como estan en el estandar
Customized approach	Implementacion alternativa que cumple el objetivo del requisito por otros medios; requiere TRA y testing derivado por el assessor
Compensating control	Control alternativo dentro del defined approach cuando hay restriccion tecnica o de negocio legitima; validado anualmente
Testing procedure	Las instrucciones especificas de como el assessor verifica el cumplimiento de un requisito (examine/observe/interview)
BAU	Business-as-usual — controles integrados en las operaciones diarias normales de seguridad, no solo ejecutados al momento del assessment
Service provider (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	Third-party service provider — termino equivalente a SP en el contexto de relaciones con terceros
DESV	Designated entities supplemental validation — validacion adicional para entidades designadas (Apendice A3)
Applicability Notes	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 “periodic” requiere TRA. Si el requisito dice “periodically”, la entidad DEBE tener una TRA documentada (Req 12.3.1). Sin TRA, no hay cumplimiento.
Asumir que los requisitos aplican igual a merchants y service providers. SP tienen frecuencias mas cortas y requisitos adicionales.
Confundir significant change con el ciclo periodico. Son dos triggers independientes. Tener el ciclo anual no exime de actuar tras un significant change, 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 “immediately” con “within 24 hours”. Para revocacion de acceso al terminar la relacion (Req 8.2.5): “immediately” no admite interpretacion de 24 horas.
Asumir que usar un TPSP PCI DSS compliant exime al cliente. El cliente mantiene su propia responsabilidad de cumplimiento.
Tratar el customized approach como una forma de relajar controles. El CA requiere mayor documentacion, TRA especifica, y testing derivado por el assessor. No es un atajo.
Ignorar las Applicability Notes. Son parte del requisito. Req 8.3.9 solo aplica con single-factor; 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: Requirements and Testing Procedures, Version 4.0.1, June 2024, PCI Security Standards Council. Fuente local: docs/PCI-DSS-v4_0_1.pdf.
- Seccion “PCI DSS Applicability Information”, p. 4-8.
- Seccion “Scope of PCI DSS Requirements”, p. 9-16.
- Seccion “Description of Timeframes Used in PCI DSS Requirements”, p. 25-27.
- Seccion “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21.
- Seccion “Approaches for Implementing and Validating PCI DSS”, p. 28-30.
- Seccion “Testing Methods for PCI DSS Requirements”, p. 31.
- Requirements 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.