Guía
Reporting y Testing
Reporting y Testing — ROC, SAQ, AoC, CCW y evidencia
Esta guia cubre el hueco operativo entre “el control existe” y “el assessment queda documentado”. Para el examen ISA, el punto critico es distinguir evidencia, metodo de testing, reporte aplicable y attestacion sin mezclar conceptos.
1. Mapa mental de validacion PCI DSS
El proceso de assessment PCI DSS sigue una secuencia de alto nivel: confirmar el scope, realizar el assessment, completar el reporte aplicable, completar la Attestation of Compliance, enviar la documentacion solicitada y, si aplica, remediar requisitos que no esten in place. (PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33)
| Paso | Que significa para el assessor | Fuente |
|---|---|---|
| Confirmar scope | Antes de probar controles, el assessor necesita saber que entorno, componentes, personas y procesos estan dentro del assessment. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
| Realizar assessment | El assessor valida requisitos aplicables mediante los testing procedures y evidencia apropiada. | PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 |
| Completar reporte aplicable | Los resultados se documentan en ROC o SAQ segun corresponda al tipo de validacion. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
| Completar AoC | La Attestation of Compliance se completa para merchants o service providers, segun aplique. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
| Enviar documentacion | La documentacion se envia a la organizacion solicitante, como payment brands, acquirers u otros requesters. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
| Remediar si hay gaps | Un requisito no esta in place si el control aun no esta implementado o esta planificado para el futuro. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
Trampa de examen: “planeado”, “en roadmap” o “se implementara antes del proximo trimestre” no equivale a in place. El estandar indica que los requisitos no se consideran in place si los controles no estan implementados o estan programados para completarse en el futuro. (PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33)
2. Testing methods: Examine, Observe, Interview
Los testing methods describen las actividades esperadas del assessor para determinar si la entidad cumple un requisito. (PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31)
| Metodo | Que prueba | Ejemplos de evidencia | Trampa de examen | Fuente |
|---|---|---|---|---|
| Examine | El assessor evalua criticamente evidencia de datos o documentos. | Politicas, procedimientos, screenshots, archivos de configuracion, audit logs, data files. | Una politica prueba que algo esta definido; no prueba por si sola que el control opera. | PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 |
| Observe | El assessor presencia una accion o ve algo en el entorno. | Personal ejecutando un proceso, system components respondiendo a input, condiciones ambientales, controles fisicos. | Una descripcion verbal de como funciona un control no sustituye observarlo cuando el testing procedure requiere observation. | PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 |
| Interview | El assessor conversa con personal individual. | Confirmacion de si una actividad se realiza, descripcion de como se realiza, conocimiento del personal. | Interview ayuda a corroborar, pero no convierte una actividad no documentada en evidencia operacional completa. | PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 |
Cuando documenta resultados, el assessor identifica las actividades de testing realizadas y el resultado de cada actividad. (PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31)
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 compliance, como payment brands y acquirers; el estandar indica que las entidades deben contactar a esas organizaciones para conocer requerimientos de reporte e instrucciones. (PCI DSS v4.0.1, seccion “Instructions and Content for Report on Compliance”, p. 32)
| Artefacto | Funcion | Lo que NO debes asumir | Fuente |
|---|---|---|---|
| ROC | Herramienta de reporting usada para documentar resultados detallados de un assessment PCI DSS. | No asumas que todo assessment usa ROC; el reporte aplicable depende del programa/requester. | PCI DSS v4.0.1, Glossary “ROC”, p. 387; seccion “PCI DSS Assessment Process”, p. 33 |
| SAQ | Herramienta de reporting usada para documentar resultados de self-assessment PCI DSS. | No asumas elegibilidad SAQ solo desde el estandar base; se debe consultar la guia SAQ correspondiente. | PCI DSS v4.0.1, Glossary “SAQ”, p. 388; seccion “PCI DSS Assessment Process”, p. 33 |
| AoC | Formulario oficial PCI SSC para merchants y service providers que attesta los resultados del assessment documentado en SAQ o ROC. | No es lo mismo que el detalle completo de un ROC o SAQ. | PCI DSS v4.0.1, Glossary “AOC”, p. 379 |
El ROC Template debe usarse como template para crear un Report on Compliance. (PCI DSS v4.0.1, seccion “Instructions and Content for Report on Compliance”, p. 32)
Para instrucciones de ROC, SAQ y submission de reportes de validacion, el estandar remite respectivamente al ROC Template, SAQ Instructions and Guidelines y Attestation of Compliance disponibles en PCI SSC. (PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33)
Confidencialidad del material de assessment
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 “Protecting Information About an Entity’s Security Posture”, p. 30)
La associated Attestation of Compliance no se considera sensible en esa seccion, y los TPSPs deben compartir su AOC con clientes. (PCI DSS v4.0.1, seccion “Protecting Information About an Entity’s Security Posture”, p. 30)
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 compliant no hace a la entidad compliant ni remueve su responsabilidad por su propio cumplimiento. (PCI DSS v4.0.1, Req 12.8.1, p. 317)
4. Evidencia de TPSP: AOC, estado de compliance y responsabilidades
El requisito 12.8 exige mantener una lista de TPSPs con quienes se comparte account data o que podrian afectar la seguridad de account data, incluyendo descripcion de los servicios provistos. (PCI DSS v4.0.1, Req 12.8.1, p. 317)
El requisito 12.8.2 exige acuerdos escritos con TPSPs que incluyan acknowledgments de responsabilidad por la seguridad de account data 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 guia del requisito 12.8.2 aclara que evidencia de cumplimiento del TPSP, como AOC, declaracion web, policy statement o responsibility matrix, no es lo mismo que el written acknowledgment exigido por el requisito. (PCI DSS v4.0.1, Req 12.8.2, p. 318)
El requisito 12.8.4 exige un programa para monitorear el estado de compliance PCI DSS de TPSPs al menos una vez cada 12 meses. (PCI DSS v4.0.1, Req 12.8.4, p. 318)
| Situacion | Respuesta de assessor | Fuente |
|---|---|---|
| El TPSP entrega un AOC vigente. | Sirve como evidencia de estado de compliance, pero no reemplaza el acuerdo escrito ni la matriz/responsabilidades aplicables. | PCI DSS v4.0.1, Req 12.8.2, p. 318; Req 12.8.4, p. 318 |
| El TPSP aparece compliant en una pagina publica. | Puede ser evidencia de compliance status, pero no es written acknowledgment del Req 12.8.2. | PCI DSS v4.0.1, Req 12.8.2, p. 318 |
| La entidad usa un TPSP compliant. | La entidad conserva responsabilidad por su propio cumplimiento PCI DSS. | PCI DSS v4.0.1, Req 12.8.1, p. 317 |
5. Compensating Controls y CCW
Los compensating controls 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)
Todo compensating control debe cumplir el intento y rigor del requisito original, proveer un nivel similar de defensa, estar above and beyond 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)
Un compensating control 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)
El assessor debe evaluar exhaustivamente los compensating controls en cada assessment anual para confirmar que abordan el riesgo que el requisito original buscaba cubrir. (PCI DSS v4.0.1, Appendix B, p. 370)
Los resultados de compensating controls 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)
Compensating Controls Worksheet (CCW)
La entidad debe usar el worksheet de Appendix C para definir compensating controls cuando los usa para cumplir un requisito PCI DSS. (PCI DSS v4.0.1, Appendix C, p. 371)
| Campo CCW | Que debe capturar | Fuente |
|---|---|---|
| Constraints | Restricciones tecnicas o de negocio legitimas que impiden cumplir el requisito original. | PCI DSS v4.0.1, Appendix C, p. 371 |
| Definition of Compensating Controls | Controles compensatorios y como cubren el objetivo original y el riesgo incrementado. | PCI DSS v4.0.1, Appendix C, p. 371 |
| Objective | Objetivo del control original y objetivo cubierto por el compensating control. | PCI DSS v4.0.1, Appendix C, p. 371 |
| Identified Risk | Riesgo adicional generado por no aplicar el control original. | PCI DSS v4.0.1, Appendix C, p. 371 |
| Validation of Compensating Controls | Como se validaron y probaron los controles compensatorios. | PCI DSS v4.0.1, Appendix C, p. 371 |
| Maintenance | Procesos y controles para mantener efectivos los compensating controls. | PCI DSS v4.0.1, Appendix C, p. 371 |
Trampa de examen: estar compliant con otros requisitos PCI DSS requeridos para el mismo item no cuenta por si solo como compensating control; Appendix B exige que sea above and beyond. (PCI DSS v4.0.1, Appendix B, p. 369)
6. CCW vs Customized Approach
Compensating controls pertenecen al defined approach y aplican cuando hay restricciones tecnicas o de negocio legitimas para cumplir el requisito exactamente como esta escrito. (PCI DSS v4.0.1, seccion “Approaches for Implementing and Validating PCI DSS”, p. 28)
Customized approach permite cumplir el Customized Approach Objective de un requisito mediante controles que no siguen estrictamente el defined requirement; como cada implementacion sera diferente, no hay testing procedures definidos y el assessor debe derivarlos. (PCI DSS v4.0.1, seccion “Approaches for Implementing and Validating PCI DSS”, p. 28)
La mayoria de requisitos puede cumplirse mediante defined o customized approach, pero los requisitos que no tienen Customized Approach Objective no admiten customized approach. (PCI DSS v4.0.1, seccion “Approaches for Implementing and Validating PCI DSS”, p. 29)
Entities that complete a Self-Assessment Questionnaire are not eligible to use a customized approach; pueden elegir que un QSA o ISA realice el assessment y lo documente en ROC Template. (PCI DSS v4.0.1, Appendix D, p. 372)
| Tema | Compensating control / CCW | Customized approach | Fuente |
|---|---|---|---|
| Camino de validacion | Defined approach. | Approach alternativo basado en el Customized Approach Objective. | PCI DSS v4.0.1, p. 28 |
| Motivo | Restriccion tecnica o de negocio legitima y documentada. | Implementacion distinta para cumplir el objetivo de seguridad. | PCI DSS v4.0.1, p. 28; Appendix D, p. 372 |
| Testing | El assessor valida la suficiencia del compensating control. | El assessor deriva testing procedures especificos para el control customizado. | PCI DSS v4.0.1, p. 28; Appendix D, p. 372 |
| Documentacion | CCW y documentacion en el reporte aplicable. | Controls matrix, targeted risk analysis, evidencia de testing y evidencia de efectividad. | PCI DSS v4.0.1, Appendix C, p. 371; Appendix D, p. 372 |
Para el detalle de defined approach, customized approach 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 attesta resultados documentados en SAQ o ROC; el ROC documenta resultados detallados. | PCI DSS v4.0.1, Glossary “AOC”, p. 379; Glossary “ROC”, p. 387 |
| Un SAQ puede usar customized approach? | No si la entidad completa SAQ; para customized approach debe optar por assessment QSA/ISA documentado en ROC Template. | PCI DSS v4.0.1, Appendix D, p. 372 |
| Un compensating control 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 |
| Un AOC de TPSP reemplaza el written acknowledgment? | No. La guia de 12.8.2 dice que AOC u otra evidencia de compliance no es lo mismo que el written acknowledgment. | PCI DSS v4.0.1, Req 12.8.2, p. 318 |
| Interview por si solo siempre basta? | No. El testing method debe alinearse con el testing procedure y la implementacion del requisito. | PCI DSS v4.0.1, seccion “Testing Methods for PCI DSS Requirements”, p. 31 |
| Un control planificado esta in place? | No. Si no esta implementado o esta programado para el futuro, el requisito no se considera in place. | PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33 |
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 “Testing Methods for PCI DSS Requirements”, p. 31)
- Si una pregunta mezcla ROC, SAQ y AoC, separa reporte detallado, self-assessment y attestacion. (PCI DSS v4.0.1, Glossary “AOC”, p. 379; Glossary “ROC”, p. 387; Glossary “SAQ”, p. 388)
- Si una pregunta menciona TPSP compliant, recuerda que la entidad conserva responsabilidad por su propio cumplimiento. (PCI DSS v4.0.1, Req 12.8.1, p. 317)
- Si una pregunta propone CCW como customized approach, rechaza la mezcla: CCW documenta compensating controls; customized approach requiere controles customizados, TRA y testing derivado. (PCI DSS v4.0.1, Appendix C, p. 371; Appendix D, p. 372)
- Si una pregunta usa “se corregira despues”, recuerda que el assessment puede requerir remediation y updated report, pero el control futuro no esta in place al momento de validacion. (PCI DSS v4.0.1, seccion “PCI DSS Assessment Process”, p. 33)