Guía
Reporting y Testing
Reportes y pruebas — ROC, SAQ, AOC, CCW y evidencia
Esta guia cubre el hueco operativo entre “el control existe” y “la evaluacion queda documentada”. Para el examen ISA, el punto critico es distinguir evidencia, metodo de prueba, reporte aplicable y atestacion sin mezclar conceptos.
1. Mapa mental de validacion PCI DSS
El proceso de evaluacion PCI DSS sigue una secuencia de alto nivel: confirmar el alcance, realizar la evaluacion, completar el reporte aplicable, completar la atestacion de cumplimiento, enviar la documentacion solicitada y, si aplica, remediar requisitos que no esten implementados. (PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA)
| Paso | Que significa para el assessor | Fuente |
|---|---|---|
| Confirmar alcance | Antes de probar controles, el assessor necesita saber que entorno, componentes, personas y procesos estan dentro de la evaluacion. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| Realizar evaluacion | El assessor valida requisitos aplicables mediante los procedimientos de prueba y evidencia apropiada. | PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA |
| Completar reporte aplicable | Los resultados se documentan en ROC o SAQ segun corresponda al tipo de validacion. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| Completar AOC | La atestacion de cumplimiento se completa para comerciantes o proveedores de servicio, segun aplique. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| Enviar documentacion | La documentacion se envia a la organizacion solicitante, como marcas de pago, adquirentes u otros solicitantes. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| Remediar si hay brechas | Un requisito no esta implementado si el control aun no esta implementado o esta planificado para el futuro. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
Trampa de examen: “planeado”, “en hoja de ruta” o “se implementara antes del proximo trimestre” no equivale a implementado. El estandar indica que los requisitos no se consideran implementados si los controles no estan implementados o estan programados para completarse en el futuro. (PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA)
2. Metodos de prueba: Examinar, Observar, Entrevistar
Los metodos de prueba describen las actividades esperadas del assessor para determinar si la entidad cumple un requisito. (PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA)
| Metodo | Que prueba | Ejemplos de evidencia | Trampa de examen | Fuente |
|---|---|---|---|---|
| Examinar | El assessor evalua criticamente evidencia de datos o documentos. | Politicas, procedimientos, capturas de pantalla, archivos de configuracion, registros de auditoria, archivos de datos. | Una politica prueba que algo esta definido; no prueba por si sola que el control opera. | PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA |
| Observar | El assessor presencia una accion o ve algo en el entorno. | Personal ejecutando un proceso, componentes del sistema respondiendo a una entrada, condiciones ambientales, controles fisicos. | Una descripcion verbal de como funciona un control no sustituye observarlo cuando el procedimiento de prueba requiere observacion. | PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA |
| Entrevistar | El assessor conversa con personal individual. | Confirmacion de si una actividad se realiza, descripcion de como se realiza, conocimiento del personal. | Entrevistar ayuda a corroborar, pero no convierte una actividad no documentada en evidencia operacional completa. | PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA |
Cuando documenta resultados, el assessor identifica las actividades de prueba realizadas y el resultado de cada actividad. (PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA)
Para repasar la diferencia entre politica, control implementado y evidencia de operacion, vuelve a pci-isa-exam-guide.md.
3. ROC, SAQ y AOC
La obligacion de cumplir o validar cumplimiento PCI DSS depende de las organizaciones que administran programas de cumplimiento, como marcas de pago y adquirentes; el estandar indica que las entidades deben contactar a esas organizaciones para conocer requerimientos de reporte e instrucciones. (PCI DSS v4.0.1, seccion “Instrucciones y Contenido para Informe de Cumplimiento”, p. 32 LA)
| Artefacto | Funcion | Lo que NO debes asumir | Fuente |
|---|---|---|---|
| ROC | Herramienta de reporte usada para documentar resultados detallados de una evaluacion PCI DSS. | No asumas que toda evaluacion usa ROC; el reporte aplicable depende del programa/solicitante. | PCI DSS v4.0.1, Glosario “ROC”, p. 387 LA; seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| SAQ | Herramienta de reporte usada para documentar resultados de autoevaluacion PCI DSS. | No asumas elegibilidad SAQ solo desde el estandar base; se debe consultar la guia SAQ correspondiente. | PCI DSS v4.0.1, Glosario “SAQ”, p. 388 LA; seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
| AOC | Formulario oficial PCI SSC para comerciantes y proveedores de servicio que atestigua los resultados de la evaluacion documentada en SAQ o ROC. | No es lo mismo que el detalle completo de un ROC o SAQ. | PCI DSS v4.0.1, Glosario “AOC”, p. 379 LA |
El template de ROC debe usarse como plantilla para crear un informe de cumplimiento. (PCI DSS v4.0.1, seccion “Instrucciones y Contenido para Informe de Cumplimiento”, p. 32 LA)
Para instrucciones de ROC, SAQ y envio de reportes de validacion, el estandar remite respectivamente al template de ROC, las instrucciones y guias SAQ, y la atestacion de cumplimiento disponibles en PCI SSC. (PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA)
Confidencialidad del material de evaluacion
El estandar identifica el ROC o SAQ como artefactos que una entidad puede considerar sensibles; tambien lista diagramas de red, diagramas de flujo de datos de cuenta, configuraciones de seguridad, estandares de configuracion y metodos/protocolos criptograficos como artefactos sensibles. (PCI DSS v4.0.1, seccion “Proteger Informacion Sobre la Postura de Seguridad de una Entidad”, p. 30 LA)
La atestacion de cumplimiento asociada no se considera sensible en esa seccion, y los TPSP deben compartir su AOC con clientes. (PCI DSS v4.0.1, seccion “Proteger Informacion Sobre la Postura de Seguridad de una Entidad”, p. 30 LA)
Trampa de examen: que un TPSP entregue AOC no significa que el cliente pueda ignorar sus responsabilidades de PCI DSS. El uso de un TPSP en cumplimiento no hace a la entidad cumplidora ni remueve su responsabilidad por su propio cumplimiento. (PCI DSS v4.0.1, Req 12.8.1, p. 317 LA)
4. Evidencia de TPSP: AOC, estado de cumplimiento y responsabilidades
El requisito 12.8 exige mantener una lista de TPSPs con quienes se comparte datos de cuenta o que podrian afectar la seguridad de datos de cuenta, incluyendo descripcion de los servicios provistos. (PCI DSS v4.0.1, Req 12.8.1, p. 317 LA)
El requisito 12.8.2 exige acuerdos escritos con TPSP que incluyan reconocimientos de responsabilidad por la seguridad de datos de cuenta que el TPSP posea, almacene, procese o transmita, o por el impacto que pueda tener sobre CHD/SAD de la entidad. (PCI DSS v4.0.1, Req 12.8.2, p. 317 LA)
La guia del requisito 12.8.2 aclara que evidencia de cumplimiento del TPSP, como AOC, declaracion web, declaracion de politica o matriz de responsabilidades, no es lo mismo que el reconocimiento escrito exigido por el requisito. (PCI DSS v4.0.1, Req 12.8.2, p. 318 LA)
El requisito 12.8.4 exige un programa para monitorear el estado de cumplimiento PCI DSS de TPSP al menos una vez cada 12 meses. (PCI DSS v4.0.1, Req 12.8.4, p. 318 LA)
| Situacion | Respuesta de assessor | Fuente |
|---|---|---|
| El TPSP entrega un AOC vigente. | Sirve como evidencia de estado de cumplimiento, pero no reemplaza el acuerdo escrito ni la matriz/responsabilidades aplicables. | PCI DSS v4.0.1, Req 12.8.2, p. 318 LA; Req 12.8.4, p. 318 LA |
| El TPSP aparece en cumplimiento en una pagina publica. | Puede ser evidencia de estado de cumplimiento, pero no es reconocimiento escrito del Req 12.8.2. | PCI DSS v4.0.1, Req 12.8.2, p. 318 LA |
| La entidad usa un TPSP en cumplimiento. | La entidad conserva responsabilidad por su propio cumplimiento PCI DSS. | PCI DSS v4.0.1, Req 12.8.1, p. 317 LA |
5. Controles compensatorios y CCW
Los controles compensatorios pueden considerarse cuando la entidad no puede cumplir un requisito PCI DSS exactamente como esta escrito por restricciones tecnicas o de negocio legitimas y documentadas, siempre que mitigue suficientemente el riesgo asociado a no cumplir el requisito original. (PCI DSS v4.0.1, Appendix B, p. 369 LA)
Todo control compensatorio debe cumplir el intento y rigor del requisito original, proveer un nivel similar de defensa, estar por encima y más allá de otros requisitos PCI DSS, atender el riesgo adicional, y cubrir el requisito actual y futuro. (PCI DSS v4.0.1, Appendix B, p. 369-370 LA)
Un control compensatorio no puede corregir una actividad perdida en el pasado; no sirve para cubrir un requisito que debio ejecutarse dos trimestres atras y no se ejecuto. (PCI DSS v4.0.1, Appendix B, p. 370 LA)
El assessor debe evaluar exhaustivamente los controles compensatorios en cada evaluacion anual para confirmar que abordan el riesgo que el requisito original buscaba cubrir. (PCI DSS v4.0.1, Appendix B, p. 370 LA)
Los resultados de controles compensatorios deben documentarse en el reporte aplicable, como ROC o SAQ, en la seccion correspondiente del requisito PCI DSS. (PCI DSS v4.0.1, Appendix B, p. 370 LA)
Ficha de control compensatorio (CCW)
La entidad debe usar la ficha del Appendix C para definir controles compensatorios cuando los usa para cumplir un requisito PCI DSS. (PCI DSS v4.0.1, Appendix C, p. 371 LA)
| Campo CCW | Que debe capturar | Fuente |
|---|---|---|
| Restricciones | Restricciones tecnicas o de negocio legitimas que impiden cumplir el requisito original. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
| Definicion de controles compensatorios | Controles compensatorios y como cubren el objetivo original y el riesgo incrementado. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
| Objetivo | Objetivo del control original y objetivo cubierto por el control compensatorio. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
| Riesgo identificado | Riesgo adicional generado por no aplicar el control original. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
| Validacion de controles compensatorios | Como se validaron y probaron los controles compensatorios. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
| Mantenimiento | Procesos y controles para mantener efectivos los controles compensatorios. | PCI DSS v4.0.1, Appendix C, p. 371 LA |
Trampa de examen: estar en cumplimiento con otros requisitos PCI DSS requeridos para el mismo item no cuenta por si solo como control compensatorio; Appendix B exige que esté por encima y más allá. (PCI DSS v4.0.1, Appendix B, p. 369 LA)
6. CCW vs enfoque personalizado
Los controles compensatorios pertenecen al enfoque definido y aplican cuando hay restricciones tecnicas o de negocio legitimas para cumplir el requisito exactamente como esta escrito. (PCI DSS v4.0.1, seccion “Enfoques para Implementar y Validar PCI DSS”, p. 28 LA)
El enfoque personalizado permite cumplir el objetivo del enfoque personalizado de un requisito mediante controles que no siguen estrictamente el requisito definido; como cada implementacion sera diferente, no hay procedimientos de prueba definidos y el assessor debe derivarlos. (PCI DSS v4.0.1, seccion “Enfoques para Implementar y Validar PCI DSS”, p. 28 LA)
La mayoria de requisitos puede cumplirse mediante enfoque definido o enfoque personalizado, pero los requisitos que no tienen objetivo del enfoque personalizado no admiten enfoque personalizado. (PCI DSS v4.0.1, seccion “Enfoques para Implementar y Validar PCI DSS”, p. 29 LA)
Las entidades que completan un cuestionario de autoevaluacion no son elegibles para usar el enfoque personalizado; pueden elegir que un QSA o ISA realice la evaluacion y la documente en el template de ROC. (PCI DSS v4.0.1, Appendix D, p. 372 LA)
| Tema | Control compensatorio / CCW | Enfoque personalizado | Fuente |
|---|---|---|---|
| Camino de validacion | Enfoque definido. | Enfoque alternativo basado en el objetivo del enfoque personalizado. | PCI DSS v4.0.1, p. 28 LA |
| Motivo | Restriccion tecnica o de negocio legitima y documentada. | Implementacion distinta para cumplir el objetivo de seguridad. | PCI DSS v4.0.1, p. 28 LA; Appendix D, p. 372 LA |
| Prueba | El assessor valida la suficiencia del control compensatorio. | El assessor deriva procedimientos de prueba especificos para el control personalizado. | PCI DSS v4.0.1, p. 28 LA; Appendix D, p. 372 LA |
| Documentacion | CCW y documentacion en el reporte aplicable. | Matriz de controles, analisis de riesgo especificos, evidencia de prueba y evidencia de efectividad. | PCI DSS v4.0.1, Appendix C, p. 371 LA; Appendix D, p. 372 LA |
Para el detalle de enfoque definido, enfoque personalizado y TRA 12.3.2, repasa pci-isa-exam-guide.md.
7. Checklist de examen
| Pregunta | Respuesta corta | Fuente |
|---|---|---|
| Un AOC reemplaza al ROC? | No. El AOC atestigua resultados documentados en SAQ o ROC; el ROC documenta resultados detallados. | PCI DSS v4.0.1, Glosario “AOC”, p. 379 LA; Glosario “ROC”, p. 387 LA |
| Un SAQ puede usar enfoque personalizado? | No si la entidad completa SAQ; para enfoque personalizado debe optar por evaluacion QSA/ISA documentada en template de ROC. | PCI DSS v4.0.1, Appendix D, p. 372 LA |
| Un control compensatorio corrige una actividad pasada no realizada? | No. No puede cubrir un requisito perdido en el pasado. | PCI DSS v4.0.1, Appendix B, p. 370 LA |
| Un AOC de TPSP reemplaza el reconocimiento escrito? | No. La guia de 12.8.2 dice que AOC u otra evidencia de cumplimiento no es lo mismo que el reconocimiento escrito. | PCI DSS v4.0.1, Req 12.8.2, p. 318 LA |
| Entrevistar por si solo siempre basta? | No. El metodo de prueba debe alinearse con el procedimiento de prueba y la implementacion del requisito. | PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA |
| Un control planificado esta implementado? | No. Si no esta implementado o esta programado para el futuro, el requisito no se considera implementado. | PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA |
8. Mini-repaso activo
- Si una pregunta ofrece “politica aprobada” como unica evidencia de operacion, sospecha: una politica puede probar definicion, no necesariamente ejecucion. (PCI DSS v4.0.1, seccion “Metodos de Prueba para Requisitos PCI DSS”, p. 31 LA)
- Si una pregunta mezcla ROC, SAQ y AOC, separa reporte detallado, autoevaluacion y atestacion. (PCI DSS v4.0.1, Glosario “AOC”, p. 379 LA; Glosario “ROC”, p. 387 LA; Glosario “SAQ”, p. 388 LA)
- Si una pregunta menciona TPSP en cumplimiento, recuerda que la entidad conserva responsabilidad por su propio cumplimiento. (PCI DSS v4.0.1, Req 12.8.1, p. 317 LA)
- Si una pregunta propone CCW como enfoque personalizado, rechaza la mezcla: CCW documenta controles compensatorios; enfoque personalizado requiere controles personalizados, TRA y pruebas derivadas. (PCI DSS v4.0.1, Appendix C, p. 371 LA; Appendix D, p. 372 LA)
- Si una pregunta usa “se corregira despues”, recuerda que la evaluacion puede requerir remediacion y reporte actualizado, pero el control futuro no esta implementado al momento de validacion. (PCI DSS v4.0.1, seccion “Proceso de Evaluacion PCI DSS”, p. 33 LA)