Temas
Temas de alto riesgo
Temas de alto riesgo para el examen ISA — PCI DSS v4.0.1
Este archivo cubre los temas con mayor probabilidad de error en el examen ISA. Para cada tema se presenta la regla exacta del estándar, las trampas más frecuentes y lo que un assessor debe buscar como evidencia.
Complementa a pci-isa-exam-guide.md (mindset y estrategia), periodicity-bau-significant-change.md (tabla de periodicidades) y recurring-activities-by-timeframe.md (vista por marco temporal).
Tema 1. Scoping: qué entra y qué no entra en scope
Regla del estándar
PCI DSS requirements apply to:
“The cardholder data environment (CDE), which is comprised of: – System components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data, and, – System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD. AND System components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data.” (PCI DSS v4.0.1, sección “Scope of PCI DSS Requirements”, p. 9)
Las tres categorías de system components in scope
| Categoría | Definición | Ejemplo |
|---|---|---|
| SPT | Almacena, procesa o transmite CHD/SAD | Servidor de pagos, terminal POS |
| Connected-to (unrestricted) | Conectividad irrestricta hacia componentes SPT | Servidor de autenticación sin segmentación |
| Security impact | Podría impactar la seguridad del CDE si se compromete | Servidor DNS, servidor de logging, servidor de redirección e-commerce |
Alta prioridad para examen: la categoría “security impact” es la que más se olvida. Un servidor que no toca CHD pero cuya compromisión permitiría acceder al CDE es in scope.
Cardholder Data vs Sensitive Authentication Data
Cardholder Data (CHD): PAN, nombre del titular, fecha de vencimiento, service code.
- El PAN es el elemento definitorio. Los otros tres solo son CHD si están presentes con el PAN.
- Almacenamiento del PAN: permitido con protección (Req 3.5).
Sensitive Authentication Data (SAD): datos completos de pista magnética (o equivalente en chip), código de verificación de tarjeta (CVV/CVC/CID), PIN/PIN blocks.
- SAD nunca puede almacenarse después de la autorización de la transacción, ni siquiera cifrado.
- Esta regla aplica incluso si el entorno no almacena PAN. (PCI DSS v4.0.1, Table 2 y Table 3, p. 4-6)
Confirmación anual de scope
La entidad debe confirmar la exactitud de su scope al menos una vez cada 12 meses y ante significant change (Req 12.5.2). Esta actividad la realiza la entidad; no reemplaza la confirmación de scope que hace el assessor durante el assessment. (PCI DSS v4.0.1, sección “Annual PCI DSS Scope Confirmation”, p. 12)
Errores comunes de examen
- Error: asumir que si el sistema no toca datos de tarjeta, está out of scope. Los sistemas con “unrestricted connectivity” o “security impact” también son in scope.
- Error: tratar CHD y SAD como sinónimos. Las reglas de almacenamiento son distintas.
- Error: creer que la confirmación de scope es tarea del assessor, no de la entidad.
Tema 2. Segmentación: no es requisito pero tiene consecuencias si se usa
Regla del estándar
“Segmentation (or isolation) of the CDE from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended.” (PCI DSS v4.0.1, sección “Segmentation”, p. 12)
Sin segmentación adecuada (“flat network”), toda la red es in scope.
Para que un componente esté out of scope, debe estar segmentado de modo que no pueda impactar la seguridad del CDE, incluso si ese componente fuera comprometido.
Testing de la segmentación
Si la entidad usa segmentación para aislar el CDE, esta debe probarse:
| Requisito | Obligación | Frecuencia | Solo SP |
|---|---|---|---|
| 11.4.5 | Pen test sobre controles de segmentación | Al menos una vez cada 12 meses y después de cualquier cambio en los controles de segmentación | No (si usan segmentación) |
| 11.4.6 | Pen test sobre controles de segmentación | Al menos una vez cada seis meses y después de cualquier cambio | Sí (solo service providers) |
El pen test debe confirmar que los controles de segmentación son operativos, efectivos, y que aíslan el CDE de todos los sistemas out of scope. (PCI DSS v4.0.1, Req 11.4.5, p. 279; Req 11.4.6, p. 280)
Errores comunes de examen
- Error: creer que el estándar exige segmentar. No es un requisito; es una recomendación.
- Error: creer que si no hay segmentación, no hay nada que probar en el Req 11.4.5. El requisito se activa solo si la entidad usa segmentación; si no la usa, no aplica.
- Error: confundir la frecuencia de SP (semestral, Req 11.4.6) con la de merchants (anual, Req 11.4.5).
Tema 3. BAU y change management: relación y diferencias
Qué es BAU en PCI DSS
BAU (Business-as-Usual) son los procesos mediante los cuales la entidad integra los controles PCI DSS en la operación diaria, no solo en el momento del assessment. El objetivo es que el ambiente se mantenga en cumplimiento entre assessments.
“An entity that implements business-as-usual processes, otherwise known as BAU, as part of their overall security strategy is taking measures to ensure that the security controls implemented to secure data and an environment continue to be implemented correctly and functioning properly as normal course of business.” (PCI DSS v4.0.1, sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19)
Relación entre BAU y change management
Los procesos de change management son parte de BAU. Antes de completar un cambio, la entidad debe:
- Evaluar el impacto potencial en el scope PCI DSS (¿el cambio trae nuevos sistemas al CDE?).
- Identificar los requisitos PCI DSS aplicables a los sistemas o redes afectadas.
- Actualizar el scope PCI DSS e implementar controles de seguridad según corresponda.
- Actualizar la documentación para reflejar los cambios implementados. (PCI DSS v4.0.1, sección BAU, p. 19-20)
Req 6.5.1: change control para todos los system components
Todo cambio en el ambiente de producción debe seguir procedimientos establecidos que incluyan, al menos:
- Razón y descripción del cambio.
- Documentación del impacto en seguridad.
- Aprobación documentada por partes autorizadas.
- Testing para verificar que el cambio no afecta adversamente la seguridad.
- Para bespoke/custom software: testing de cumplimiento con Req 6.2.4 antes de desplegar en producción.
- Procedimientos para tratar fallas y retornar a un estado seguro. (PCI DSS v4.0.1, Req 6.5.1, p. 155)
Req 6.5.2: confirmar PCI DSS tras significant change
“Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.” (PCI DSS v4.0.1, Req 6.5.2, p. 156)
Testing procedure: el assessor examina documentación de significant changes, entrevista personal y observa los sistemas/redes afectadas para verificar que la entidad confirmó que los requisitos PCI DSS aplicables estaban en place en todos los sistemas o redes nuevos o cambiados.
Applicability note: estos significant changes también deben capturarse y reflejarse en la actividad anual de confirmación de scope del Req 12.5.2.
Ejemplos de requisitos impactados: actualización de diagramas de red y flujos de datos, configuración de sistemas según estándares, protección con FIM/anti-malware/patches/logging, verificación de que no se almacena SAD, inclusión de nuevos sistemas en el proceso trimestral de escaneo de vulnerabilidades, escaneos de vulnerabilidades post-cambio (Req 11.3.1.3 y 11.3.2.1). (PCI DSS v4.0.1, Req 6.5.2, p. 156)
Lo que el assessor busca como evidencia
| Para BAU | Para change management |
|---|---|
| Mecanismos de monitoreo continuo en operación (IDS/IPS, FIM, anti-malware, logs de acceso) | Change control tickets con: descripción, impacto en seguridad, aprobación, resultados de testing |
| Registros de revisiones periódicas (scan reports, log reviews, ruleset reviews) | Documentación de evaluación de impacto en PCI DSS scope pre-cambio |
| Evidencia de respuesta a fallas de controles | Post-change scans (Req 11.3.1.3, 11.3.2.1) y confirmación de requisitos (Req 6.5.2) |
| Política que asigna responsabilidad de cumplimiento PCI DSS | Diagramas de red actualizados que reflejan los cambios |
Errores comunes de examen
- Error: confundir “política de change management documentada” con “evidencia de que el proceso opera”. El assessor necesita ambas.
- Error: olvidar que Req 6.5.2 exige confirmación activa de PCI DSS post-cambio. No basta con el change ticket.
- Error: creer que BAU solo aplica a los requisitos marcados como tal en el estándar. El estándar indica que la entidad debe adoptar BAU adicionales según su entorno.
Tema 4. Req 6.4.1 y 6.4.2: protección de aplicaciones web públicas
Contexto: transición de 6.4.1 a 6.4.2
Este es uno de los temas de mayor confusión por la transición de requisitos:
- Req 6.4.1 fue el requisito vigente hasta el 31 de marzo de 2025. Ofrecía dos opciones: (a) revisión anual por especialista en seguridad de aplicaciones, o (b) solución técnica automatizada que detecta y previene ataques de forma continua. (PCI DSS v4.0.1, Req 6.4.1, p. 150)
- Req 6.4.2 reemplaza a 6.4.1 desde el 31 de marzo de 2025. Exige únicamente la opción (b): solución automatizada que detecta y previene ataques de forma continua (ya no se puede elegir entre revisión anual o WAF). (PCI DSS v4.0.1, Req 6.4.2, p. 151-152)
Applicability note de Req 6.4.1: “This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.” (PCI DSS v4.0.1, Req 6.4.1, p. 151)
Applicability note de Req 6.4.2: “This new requirement will replace Requirement 6.4.1 once its effective date is reached. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.” (PCI DSS v4.0.1, Req 6.4.2, p. 152)
Req 6.4.1 (vigente hasta 31/03/2025): dos opciones
Opción A — Revisión manual o automatizada:
- Al menos una vez cada 12 meses y después de significant changes.
- Por una entidad especializada en seguridad de aplicaciones.
- Incluye, como mínimo, todos los ataques comunes del Req 6.2.4.
- Todas las vulnerabilidades son clasificadas conforme al Req 6.3.1.
- Todas las vulnerabilidades son corregidas.
- La aplicación es re-evaluada después de las correcciones.
Opción B — Solución técnica automatizada:
- Instalada frente a las aplicaciones web públicas.
- Activamente en ejecución y actualizada.
- Genera audit logs.
- Configurada para bloquear ataques o generar alertas que son investigadas de forma inmediata.
Ejemplo: WAF (Web Application Firewall) instalado frente a aplicaciones web públicas. (PCI DSS v4.0.1, Req 6.4.1, p. 150-151)
Req 6.4.2 (requerido desde 01/04/2025): solo opción B
El requisito exige exclusivamente la solución automatizada que detecta y previene ataques de forma continua. No existe opción de revisión anual por especialista como alternativa. Los elementos son los mismos que la Opción B del Req 6.4.1.
Esta evaluación NO es lo mismo que los scans de 11.3.1/11.3.2
Applicability note: “This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2.” (PCI DSS v4.0.1, Req 6.4.1, p. 151)
Lo que el assessor busca como evidencia
Para Req 6.4.2 (post-31/03/2025):
- Configuración del sistema (WAF u otra solución automatizada): instalada frente a aplicaciones web, activa, actualizada.
- Audit logs de la solución.
- Entrevista con personal responsable.
Errores comunes de examen
- Error: creer que después del 31/03/2025 aún se puede elegir entre revisión anual por especialista o WAF. Desde esa fecha solo es válida la solución automatizada continua (Req 6.4.2).
- Error: confundir el assessment de 6.4.1/6.4.2 con los scans de vulnerabilidades del Req 11.3.1/11.3.2. Son controles distintos.
- Error: no verificar que la solución automatizada genera audit logs y está activamente actualizada.
Tema 5. Req 11.x: testing de sistemas y redes
Mapa de Req 11.x
| Req | Control | Frecuencia | Solo SP |
|---|---|---|---|
| 11.2.1 | Escaneo de puntos de acceso inalámbrico no autorizados | Al menos una vez cada tres meses | No |
| 11.3.1 | Escaneo interno de vulnerabilidades | Al menos una vez cada tres meses; high/critical resueltos; rescan hasta confirmar | No |
| 11.3.1.1 | Vulnerabilidades de menor riesgo (no high/critical) | Según TRA (Req 12.3.1); rescan según necesidad. Requerido desde 31/03/2025 | No |
| 11.3.1.2 | Escaneo autenticado interno | Al menos una vez cada tres meses. Requerido desde 31/03/2025 | No |
| 11.3.1.3 | Escaneo interno post-significant-change | Post-significant change; high/critical resueltos | No |
| 11.3.2 | Escaneo externo de vulnerabilidades por ASV | Al menos una vez cada tres meses; passing scan | No |
| 11.3.2.1 | Escaneo externo post-significant-change | Post-significant change; passing scan | No |
| 11.4.1 | Metodología de pen testing definida y documentada | No es periódico; es un requisito de tener la metodología activa | No |
| 11.4.2 | Pen test interno | Al menos una vez cada 12 meses y post-significant change | No |
| 11.4.3 | Pen test externo | Al menos una vez cada 12 meses y post-significant change | No |
| 11.4.4 | Remediación de hallazgos del pen test | Según risk ranking del Req 6.3.1; re-testing para confirmar | No |
| 11.4.5 | Pen test sobre controles de segmentación | Al menos una vez cada 12 meses y post-cambio en segmentación | No (si usan segmentación) |
| 11.4.6 | Pen test sobre controles de segmentación | Al menos una vez cada seis meses y post-cambio | Solo SP |
| 11.4.7 | Soporte a clientes para pen testing externo | Sin frecuencia fija (control de capacidad) | Solo SP multi-tenant |
| 11.5.1 | IDS/IPS: monitoreo continuo en perímetro y puntos críticos del CDE | Continuo | No |
| 11.5.1.1 | Detección de canales de comunicación encubiertos de malware | Continuo. Requerido desde 31/03/2025 | Solo SP |
| 11.5.2 | FIM/change-detection: comparación de archivos críticos | Al menos una vez por semana | No |
| 11.6.1 | Detección de cambios en páginas de pago (tamper detection) | Al menos una vez por semana o según TRA (Req 12.3.1) | No (aplica a e-commerce) |
Fuentes: PCI DSS v4.0.1, Req 11.2.1 (p. 261), 11.3.1 (p. 266), 11.3.1.1 (p. 268), 11.3.1.2 (p. 269), 11.3.1.3 (p. 270), 11.3.2 (p. 271), 11.3.2.1 (p. 272), 11.4.1-11.4.7 (p. 274-282), 11.5.1 (p. 283), 11.5.1.1 (p. 284), 11.5.2 (p. 286), 11.6.1 (p. 288).
Req 11.3.1 a fondo: escaneo interno trimestral
El requisito exige:
- Ejecutar el scan al menos una vez cada tres meses.
- Resolver todas las vulnerabilidades de alto riesgo o críticas (según el risk ranking definido en Req 6.3.1).
- Ejecutar rescan para confirmar que las vulnerabilidades high y critical quedaron resueltas.
- Mantener la herramienta de escaneo actualizada con la información de vulnerabilidades más reciente.
- Ejecutado por personal calificado con independencia organizacional del tester.
Nota: no se exige QSA ni ASV para el scan interno. (PCI DSS v4.0.1, Req 11.3.1, p. 266)
Req 11.3.1.1: vulnerabilidades de menor riesgo (nuevo, desde 31/03/2025)
Las vulnerabilidades no clasificadas como high o critical deben gestionarse según el riesgo definido en la TRA de la entidad (Req 12.3.1). La TRA debe incluir como mínimo: identificación de activos protegidos, amenazas y factores de probabilidad/impacto. (PCI DSS v4.0.1, Req 11.3.1.1, p. 268)
Req 11.4.1: metodología de pen testing
La entidad debe definir, documentar e implementar una metodología que incluya, como mínimo:
- Enfoques de pen testing aceptados por la industria.
- Cobertura del perímetro completo del CDE y sistemas críticos.
- Testing desde adentro y desde afuera de la red.
- Validación de controles de segmentación y reducción de scope.
- Pen testing de capa de aplicación (vulnerabilidades del Req 6.2.4, como mínimo).
- Pen testing de capa de red (todos los componentes que soporten funciones de red y sistemas operativos).
- Revisión y consideración de amenazas y vulnerabilidades de los últimos 12 meses.
- Enfoque documentado para evaluar y abordar el riesgo de vulnerabilidades encontradas.
- Retención de resultados de pen testing y actividades de remediación durante al menos 12 meses. (PCI DSS v4.0.1, Req 11.4.1, p. 274-275)
Req 11.4.2 y 11.4.3: pen test interno y externo
Ambos deben ejecutarse al menos una vez cada 12 meses y después de cualquier actualización o cambio significativo de infraestructura o aplicación. El tester (interno o externo calificado) debe tener independencia organizacional respecto del componente que prueba; no se exige que sea QSA ni ASV.
Evidencia requerida: scope of work + resultados del pen test más reciente. (PCI DSS v4.0.1, Req 11.4.2, p. 276; Req 11.4.3, p. 277)
Req 11.5.2: FIM semanal
El mecanismo de change-detection (por ejemplo, FIM) debe:
- Alertar al personal ante modificación no autorizada (incluyendo cambios, adiciones y eliminaciones) de archivos críticos.
- Realizar comparaciones de archivos críticos al menos una vez por semana.
Los archivos críticos son aquellos que no cambian regularmente pero cuya modificación podría indicar compromiso del sistema. Los productos de FIM generalmente incluyen una lista preconfigurada de archivos críticos del sistema operativo; la entidad debe definir archivos críticos adicionales de aplicaciones propias. (PCI DSS v4.0.1, Req 11.5.2, p. 286)
Req 11.6.1: tamper detection en páginas de pago
Aplica a entidades con páginas de pago en e-commerce. El mecanismo debe:
- Alertar ante modificación no autorizada de los HTTP headers de seguridad y el contenido de scripts de las páginas de pago según lo recibe el browser del consumidor.
- Estar configurado para evaluar los HTTP headers y las páginas de pago.
- Funcionar al menos una vez por semana O a la frecuencia definida en la TRA de la entidad (Req 12.3.1).
(PCI DSS v4.0.1, Req 11.6.1, p. 288)
Diferencias críticas en el bloque 11.x
| Diferencia | Detalle |
|---|---|
| Scan interno vs. scan externo (ASV) | El externo exige ASV certificado; el interno puede ser personal interno calificado |
| Scan trimestral vs. post-significant-change | Req 11.3.1 = trimestral (calendario); Req 11.3.1.3 = event-driven (post-cambio) |
| Pen test anual vs. semestral de segmentación | 11.4.5 = anual (todos); 11.4.6 = semestral (solo SP) |
| FIM vs. tamper detection de pago | 11.5.2 = archivos críticos del sistema (semanal fijo); 11.6.1 = páginas de pago (semanal o TRA) |
Lo que el assessor busca como evidencia en 11.x
| Req | Evidencia principal |
|---|---|
| 11.3.1 | Reportes de scan trimestrales de los últimos 12 meses; rescan reports confirmando resolución de high/critical |
| 11.3.2 | Reportes de passing scan de ASV de los últimos 12 meses |
| 11.4.2/11.4.3 | Metodología documentada + scope of work + resultados del pen test (incluye retención mínima 12 meses) |
| 11.4.5/11.4.6 | Resultados del pen test sobre segmentación mostrando que el CDE está aislado |
| 11.5.2 | Configuración de FIM + reportes/alertas de monitoreo semanal |
| 11.6.1 | Configuración del mecanismo + registros de evaluación semanal o según TRA |
Errores comunes de examen
- Error: creer que el scan trimestral de 11.3.1 no exige rescan. Sí lo exige hasta confirmar resolución de todas las vulnerabilidades high y critical.
- Error: confundir pen test con vulnerability scan. Son controles distintos con propósitos y evidencias diferentes.
- Error: olvidar que 11.4.2 y 11.4.3 también se activan post-significant change, no solo anualmente.
- Error: creer que 11.4.5 aplica solo a service providers. La prueba de segmentación aplica a todo el que usa segmentación; 11.4.6 es el adicional de SP (semestral).
- Error: confundir la frecuencia de FIM (semanal, fija) con la de tamper detection de pago (semanal o TRA).
Tema 6. Req 12.3.1: Targeted Risk Analysis (TRA)
Regla del estándar
“For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.” (PCI DSS v4.0.1, Req 12.3.1, p. 296)
Applicability note: “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”
Para qué sirve la TRA en PCI DSS
La TRA en PCI DSS no es una evaluación de riesgo empresarial amplia. Es específica: permite a la entidad justificar la frecuencia de controles que el estándar describe como “periodically” (periódicamente), sin fijar un intervalo exacto. La entidad elige la frecuencia basándose en el riesgo documentado para su entorno.
Esta TRA (targeted) es diferente de una evaluación de riesgos empresarial (enterprise-wide risk assessment), que el estándar recomienda pero no exige. (PCI DSS v4.0.1, Req 12.3.1, p. 297)
Requisitos que dependen de TRA (requieren Req 12.3.1)
Ver tabla completa en periodicity-bau-significant-change.md. Ejemplos representativos:
| Req | Control que depende de TRA |
|---|---|
| 11.3.1.1 | Frecuencia de remediación de vulnerabilidades de menor riesgo |
| 11.6.1 | Frecuencia de tamper detection (si se elige alternativa a semanal) |
| 12.6.2 | Frecuencia de revisión de políticas de seguridad |
| 8.6.3 | Frecuencia de rotación de passwords de cuentas de aplicación/sistema |
| 9.5.1.2.1 | Frecuencia de revisión de dispositivos POI |
| 10.4.2.1 | Frecuencia de revisión de logs no críticos |
Los cuatro elementos obligatorios de cada TRA
- Identificación de los activos protegidos.
- Identificación de la(s) amenaza(s) que el requisito protege.
- Identificación de factores que contribuyen a la probabilidad y/o impacto de que la amenaza se materialice.
- Análisis resultante que determina y justifica cómo la frecuencia o proceso definido por la entidad minimiza la probabilidad/impacto de la amenaza.
Más: revisión anual de cada TRA para validar si sigue siendo válida.
Lo que el assessor busca como evidencia
- Política/proceso que define cómo la entidad ejecuta TRAs.
- Para cada requisito con TRA: documento de TRA con los cuatro elementos, la frecuencia elegida y la justificación.
- Evidencia de revisión anual de cada TRA.
- Si la TRA fue actualizada: versión anterior y nueva, con justificación del cambio.
Errores comunes de examen
- Error: creer que “periodically” significa “anualmente”. Significa “según la TRA de la entidad”. La entidad puede elegir frecuencias distintas a 12 meses si las justifica en la TRA.
- Error: confundir Req 12.3.1 (TRA para actividades periódicas) con Req 12.3.2 (TRA para customized approach). Son TRAs con propósitos distintos.
- Error: presentar una evaluación de riesgo empresarial genérica como evidencia de TRA. Las TRAs de 12.3.1 son requisito-específicas.
- Error: olvidar que cada TRA debe revisarse al menos una vez cada 12 meses.
Tema 7. Req 12.5.2: confirmación anual del scope PCI DSS
Regla del estándar
“PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.” (PCI DSS v4.0.1, Req 12.5.2, p. 305)
La validación de scope incluye, como mínimo:
- Identificar todos los flujos de datos para las distintas etapas de pago (autorización, captura, liquidación, contracargos, reembolsos) y canales de aceptación.
- Actualizar todos los diagramas de flujo de datos (Req 1.2.4).
- Identificar todas las ubicaciones donde se almacenan, procesan y transmiten datos de cuenta, incluyendo ubicaciones fuera del CDE definido, aplicaciones que procesan CHD, transmisiones entre sistemas y redes, y backups de archivos.
- Identificar todos los system components en el CDE, conectados al CDE o que podrían impactar la seguridad del CDE.
- Identificar todos los controles de segmentación en uso y los entornos de los cuales el CDE está segmentado, incluyendo justificación de por qué esos entornos están out of scope.
- Identificar todas las conexiones de terceros con acceso al CDE.
- Confirmar que todos los flujos de datos, datos de cuenta, system components, controles de segmentación y conexiones de terceros identificados están incluidos en el scope. (PCI DSS v4.0.1, Req 12.5.2, p. 305)
Esta actividad NO reemplaza la confirmación de scope del assessor
“This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the annual assessment.” (PCI DSS v4.0.1, Req 12.5.2, p. 306)
Frecuencia y triggers
- Al menos una vez cada 12 meses (calendario).
- Ante significant change al entorno in scope (event-driven).
Nota: los significant changes deben también reflejarse en la confirmación de scope (Req 6.5.2 hace referencia cruzada a Req 12.5.2).
Lo que el assessor busca como evidencia
- Resultados documentados de la revisión de scope (puede ser un documento o registro formal).
- Entrevistas con personal que confirmen que las revisiones se realizaron.
- Que la revisión cubra todos los elementos listados en el requisito (flujos, ubicaciones, system components, segmentación, terceros).
- Documentación de que los significant changes durante el año fueron incorporados.
Req 12.5.2.1 (solo SP): revisión adicional
“Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment.” (PCI DSS v4.0.1, Req 12.5.2.1, p. 306-307)
Los service providers deben confirmar su scope cada seis meses en lugar de cada 12 meses.
Errores comunes de examen
- Error: creer que la confirmación de scope la realiza el assessor. La hace la entidad; el assessor valida que la entidad la realizó correctamente.
- Error: olvidar el trigger por significant change. No basta con hacer la revisión anual.
- Error: olvidar que para service providers la frecuencia es semestral (Req 12.5.2.1), no anual.
Tema 8. Evidencia: qué busca el assessor y cómo distinguir tipos
Los tres tipos de testing procedure
| Método | Qué hace el assessor |
|---|---|
| Examine | Revisa documentos, configuraciones, registros, reportes, políticas |
| Observe | Observa procesos, actividades, mecanismos en operación |
| Interview | Entrevista a personal responsable |
Una política bien documentada pero que nadie ejecuta opera solo satisface el testing “examine policy”. El assessor necesita evidencia de operación real (logs, reportes, registros de actividades realizadas, entrevistas que confirmen cómo se ejecuta). (PCI DSS v4.0.1, sección “Testing Methods”, p. 31)
Distinciones que confunden en examen
| Escenario de confusión | Distinción correcta |
|---|---|
| Política de patch management vs. registros de patches aplicados | La política es necesaria pero no suficiente. Se necesita evidencia de patches aplicados dentro de los plazos del Req 6.3.3. |
| Procedimiento de revisión de logs vs. registros de que la revisión ocurrió | El procedimiento documentado satisface el “examine procedure”. Los logs de revisión diaria satisfacen el “examine records”. |
| Metodología de pen test documentada vs. resultados del pen test | La metodología (Req 11.4.1) es un requisito separado de la ejecución del pen test (Req 11.4.2/11.4.3). |
| TRA documentada vs. evidencia de frecuencia ejecutada | La TRA justifica la frecuencia pero la evidencia de que la actividad se realizó a esa frecuencia es independiente. |
Errores comunes de examen
- Error: presentar una política o procedimiento como evidencia de que un control opera. Una política describe la intención; la evidencia de operación demuestra la ejecución.
- Error: confundir “definido” con “implementado”. El estándar distingue entre “processes are defined” (política/procedimiento) y “processes are implemented” (evidencia operacional).
- Error: olvidar que el assessor puede usar sampling al revisar poblaciones grandes, pero la entidad no puede aplicar PCI DSS solo a una muestra de su entorno.
Definicion de significant change (referencia)
“There are several requirements that specify activities to be performed upon a significant change in an entity’s environment. While what constitutes a significant change is highly dependent on the configuration of a given environment, each of the following activities, at a minimum, has potential impacts on the security of the CDE and must be considered and evaluated to determine whether a change is a significant change for an entity in the context of related PCI DSS requirements:
- New hardware, software, or networking equipment added to the CDE.
- Any replacement or major upgrades of hardware and/or software in the CDE.
- Any changes in the flow or storage of account data.
- Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
- Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring).
- Any changes to third-party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.” (PCI DSS v4.0.1, sección “Timeframes in PCI DSS Requirements”, p. 25-26)
Resumen de alta prioridad para examen
| Tema | Trampa principal |
|---|---|
| Scoping | ”Security impact” como categoría in scope — no requiere contacto directo con CHD/SAD |
| SAD | No almacenable después de autorización, ni siquiera cifrado, incluso sin PAN |
| Segmentación | No es requisito del estándar; si se usa, debe probarse (11.4.5/11.4.6) |
| Req 6.4.2 | Desde 31/03/2025 solo solución automatizada es válida; no hay opción de revisión anual |
| Req 6.5.2 | Confirmar activamente PCI DSS post-significant change, no solo documentar el cambio |
| Req 11.3.1 | Exige rescan hasta confirmar resolución de high/critical; trimestral es la frecuencia mínima |
| Req 11.4.5 vs. 11.4.6 | 11.4.5 = anual (todos); 11.4.6 = semestral (solo SP) |
| Req 12.3.1 | ”Periodically” ≠ anualmente; la TRA define la frecuencia y debe revisarse cada 12 meses |
| Req 12.5.2 | La entidad hace la confirmación de scope; el assessor valida que la hizo |
| Evidencia | Política + evidencia de operación son requisitos separados |
Fuentes consultadas
- PCI DSS v4.0.1, sección “Scope of PCI DSS Requirements”, p. 9-10
- PCI DSS v4.0.1, sección “Segmentation”, p. 12
- PCI DSS v4.0.1, sección “Annual PCI DSS Scope Confirmation”, p. 12
- PCI DSS v4.0.1, Table 2 y Table 3 (Account Data Element Storage Requirements), p. 4-6
- PCI DSS v4.0.1, sección “Best Practices for Implementing PCI DSS into Business-as-Usual Processes”, p. 19-21
- PCI DSS v4.0.1, sección “Timeframes in PCI DSS Requirements” (definición de significant change), p. 25-26
- PCI DSS v4.0.1, sección “Testing Methods”, p. 31
- PCI DSS v4.0.1, Req 6.5.1, p. 155
- PCI DSS v4.0.1, Req 6.5.2, p. 156
- PCI DSS v4.0.1, Req 6.4.1, p. 150-151
- PCI DSS v4.0.1, Req 6.4.2, p. 151-152
- PCI DSS v4.0.1, Req 11.2.1, p. 261
- PCI DSS v4.0.1, Req 11.3.1, p. 266
- PCI DSS v4.0.1, Req 11.3.1.1, p. 268
- PCI DSS v4.0.1, Req 11.3.1.2, p. 269
- PCI DSS v4.0.1, Req 11.3.1.3, p. 270
- PCI DSS v4.0.1, Req 11.3.2 y 11.3.2.1, p. 271-272
- PCI DSS v4.0.1, Req 11.4.1, p. 274-275
- PCI DSS v4.0.1, Req 11.4.2, p. 276
- PCI DSS v4.0.1, Req 11.4.3, p. 277
- PCI DSS v4.0.1, Req 11.4.4, p. 278
- PCI DSS v4.0.1, Req 11.4.5, p. 279
- PCI DSS v4.0.1, Req 11.4.6, p. 280
- PCI DSS v4.0.1, Req 11.5.1, p. 283
- PCI DSS v4.0.1, Req 11.5.1.1, p. 284
- PCI DSS v4.0.1, Req 11.5.2, p. 286
- PCI DSS v4.0.1, Req 11.6.1, p. 288
- PCI DSS v4.0.1, Req 12.3.1, p. 296-297
- PCI DSS v4.0.1, Req 12.5.2, p. 305-306
periodicity-bau-significant-change.md(base canónica de periodicidades)recurring-activities-by-timeframe.md(vista por marco temporal)pci-isa-exam-guide.md(mindset de assessor y estrategia de examen)