¿Qué hay de nuevo en PCI DSS 4.0? Los cambios principales que necesitas saber
Lanzado en 2006, el Estándar de Seguridad de Datos del Instituto de la Tarjeta de Pago (PCI DSS) es un conjunto de estándares de seguridad destinados a garantizar que todas las empresas que procesan, almacenan, transmiten o impactan en la seguridad de los datos de los titulares de tarjetas mantengan un entorno seguro.
Ahora, el estándar está evolucionando para mantenerse al día con el estado del comercio electrónico y amenazas cibernéticas más sofisticadas. La última evolución del estándar — PCI DSS v4.0 — fue lanzada el 31 de marzo del 2022.
Entendemos que mantenerse al día con los últimos cambios en los requisitos de cumplimiento como PCI DSS puede ser difícil. Es por eso que hacemos parte de nuestra misión mantener a nuestros clientes informados sobre cualquier cambio que pudiera afectar su entorno y mantener nuestra plataforma actualizada.
En este artículo, explicamos los cambios realizados en PCI DSS y qué significan para tu organización.
¿Qué es PCI 4.0?
PCI 4.0 es la última iteración importante del estándar de la industria de tarjetas de pago e implementa cambios significativos en los requisitos, centrándose más en mantener una seguridad continua así como en añadir nuevos métodos para cumplir con los requisitos.
El objetivo principal de PCI DSS 4.0 es continuar evolucionando el estándar para satisfacer las cambiantes necesidades de la industria de tarjetas de pago y las nuevas tecnologías que se implementan diariamente.
Lecturas recomendadas
Historia del PCI: Cómo se creó el estándar
Cambios en PCI DSS 4.0 a simple vista
PCI DSS v4.0 incluye una variedad de cambios que apuntan a cumplir cuatro objetivos clave:
- continuar satisfaciendo las necesidades de la industria de pagos
- promover la seguridad como un proceso continuo
- añadir flexibilidad y métodos adicionales para mantener la seguridad de los pagos
- mejorar los métodos y procedimientos de validación de pagos
A continuación se presenta una visión general de alto nivel de estos cambios. Puedes encontrar un resumen más detallado al final del blog.
1. Añadir un enfoque personalizado para implementar y validar PCI DSS
El cambio más significativo es su implementación de un nuevo método para cumplir con los requisitos llamado enfoque personalizado.
El enfoque personalizado proporciona a las organizaciones la flexibilidad para cumplir con los objetivos de seguridad de los requisitos de PCI DSS utilizando nueva tecnología y controles innovadores. Esto permite a las organizaciones cumplir con los estrictos requisitos de PCI DSS de una manera más personalizada y flexible.
El evaluador validará que los controles personalizados cumplan con los requisitos de PCI DSS mediante la revisión de la documentación del enfoque personalizado de la entidad (incluyendo una matriz de controles y un análisis de riesgos dirigido) y el desarrollo de un procedimiento para validar los controles.
Es importante entender que los controles personalizados no son controles compensatorios. Los controles compensatorios son controles mitigadores que se requieren cuando una organización no puede cumplir con un requisito debido a una restricción técnica o comercial legítima y documentada. Los controles personalizados, por otro lado, son una alternativa flexible para cumplir con los requisitos estrictos.
2. Requisitos actualizados
Además, ha habido mejoras importantes en los requisitos en PCI DSS 4.0. Estos incluyen:
- Controles adicionales de autenticación, incluidos estrictos requisitos de autenticación multifactor al acceder al entorno de datos del titular de la tarjeta.
- Requisitos de contraseña actualizados, incluyendo el aumento del requisito de longitud de contraseña de 8 caracteres a 12.
- Cambios en los requisitos relacionados con cuentas compartidas, grupales y genéricas.
- Roles y responsabilidades claramente definidos necesarios para cada requisito.
3. Nuevos requisitos
También se han implementado nuevos requisitos para prevenir y detectar amenazas nuevas y continuas contra la industria de pagos, incluidos ataques de phishing, comercio electrónico y e-skimming.
4. Informes de evaluación de PCI DSS mejorados
Finalmente, se han realizado mejoras en el cuestionario de autoevaluación (SAQ) así como en la plantilla del Informe de Cumplimiento (RoC) para ayudar a guiar a las organizaciones al auto-atestiguar y a los evaluadores al documentar los resultados.
Para una descripción más detallada de los cambios entre PCI DSS 3.2.1 y 4.0, consulte la tabla al final de esta publicación.
Lectura recomendada
Requisitos de PCI DSS 4.0: un análisis profundo de los últimos cambios y cómo afectan a su organización
¿Cuándo entra en vigor PCI DSS 4.0?
PCI DSS 4.0 se lanzó el 31 de marzo de 2022 y está en vigor hoy. Hasta el 31 de marzo de 2024, la versión anterior de PCI DSS — v3.2.1 — también permanecerá activa para dar tiempo a las organizaciones a adoptar la última versión del estándar. También hay requisitos adicionales que solo se considerarán como mejores prácticas hasta el 31 de marzo de 2025.
Echemos un vistazo más de cerca a la línea de tiempo de implementación de PCI DSS 4.0 a continuación.
Fuente: sitio web de PCI SSC
Período de transición de PCI DSS v3.2.1 a v4.0
PCI DSS v3.2.1 permanecerá activo desde marzo de 2022 hasta el 31 de marzo de 2024. Estos dos años después de la publicación de v4.0 están destinados a proporcionar a las organizaciones el tiempo suficiente para revisar los cambios en v4.0, actualizar sus plantillas y formularios de informes, e implementar nuevos controles para cumplir con los requisitos actualizados en v4.0.
Durante este período de transición, el Entorno de Datos del Titular de la Tarjeta (CDE) de una organización puede ser evaluado utilizando PCI DSS v3.2.1 o v4.0.
El 31 de marzo de 2024, PCI DSS v3.2.1 será retirado y v4.0 se convertirá en la única versión activa del nuevo estándar.
Implementación de requisitos con fecha futura en PCI DSS 4.0
Las organizaciones tendrán un año adicional después del retiro de la v3.2.1 para adoptar los requisitos que han sido identificados como con fecha futura en la v4.0.
Antes del 31 de marzo de 2025, las organizaciones no están obligadas a validar estos nuevos requisitos. Sin embargo, si las organizaciones han implementado controles para cumplir con los nuevos requisitos, se les recomienda que los evalúen antes.
Después del 31 de marzo de 2025, estos requisitos con fecha futura entrarán en vigor y deberán ser completamente considerados como parte de una evaluación de PCI DSS.
¿Qué significan estos cambios para las organizaciones que ya están certificadas por PCI?
En respuesta a los cambios de PCI DSS 4.0, las organizaciones que ya están certificadas por PCI deben comenzar investigando. Las organizaciones deben revisar los cambios en el documento oficial PCI DSS 4.0 del sitio web del Consejo de Normas de Seguridad PCI (PCI SSC) para ver qué pasos deben tomar para estar preparadas para la implementación de la versión 4.0 en marzo de 2024.
Las organizaciones que busquen orientación sobre los cambios que deben realizar pueden contactar a su asesor de seguridad calificado en PCI DSS o a un gerente de cumplimiento de Secureframe. Un gerente de cumplimiento de Secureframe le ayudará a entender los nuevos requisitos, los cambios a los requisitos actuales y cómo puede implementar controles dentro de su entorno para cumplir con los cambios en la versión 4.0.
¿Qué significan estos cambios para las organizaciones que buscan la certificación PCI por primera vez?
Las organizaciones que buscan cumplir con PCI DSS deberían abordar la versión 4.0 de manera similar a como lo harían con la versión 3.2.1.
Comience contactando a un gerente de cumplimiento de Secureframe para ayudar a determinar el alcance de su servicio y entorno. Esto le ayudará a entender qué requisitos debe cumplir. Luego, utilice la plataforma Secureframe para completar las tareas de la plataforma y remediar las pruebas automatizadas con el apoyo de nuestros gerentes de cumplimiento. Finalmente, seleccione uno de nuestros QSA socios para realizar el trabajo de campo directamente dentro de la plataforma.
Lecturas Recomendadas
Agilice el Cumplimiento de PCI DSS con Secureframe
Cómo Secureframe puede ayudarle a cumplir con los requisitos de PCI DSS 4.0
El cumplimiento de PCI DSS 4.0 será obligatorio a partir del 31 de marzo de 2024. Si no está seguro de cómo cumplir con los cambios de requisitos, Secureframe puede ayudarle.
Utilice la tabla a continuación para ver los cambios en los requisitos de PCI 4.0 y cómo Secureframe ayuda a los clientes a cumplir con ellos lado a lado.
| PCI DSS 4.0 requirement change | How Secureframe helps support customers |
| Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Utilize our policy templates to assign responsible teams and individuals to PCI DSS principles allowing personnel to acknowledge their responsibility regularly, and assign individual responsibility to specific PCI DSS requirements. |
|---|---|
| Perform a targeted risk analysis to determine frequency of regularly recurring tasks | For each applicable targeted risk analysis required, use Secureframe’s risk management platform to specifically identify the factors that contribute to risk, resulting analysis, and automate the notifications for regular review. |
| Document and confirm PCI DSS scope at least every 12 months | Manage PCI DSS scope within the Secureframe platform, utilize our scoping template for proper documentation, and assign owners to be automatically notified when a review needs to be performed. |
| Authentication updates such as password policy and MFA | Integrate your technology to the Secureframe platform to automatically monitor new PCI DSS authentication requirements such as multi factor authentication for all access, 12 character password requirements, and dynamic analysis of access. |
| Payment page security | Secureframe has established and vetted partners in the script management space to help our customers manage the inventory and integrity of scripts affordably and effectively. |
| Security Awareness Training | Secureframe offers PCI DSS and cybersecurity awareness training including content related to phishing and social engineering to keep your personnel aware of current common attacks. |
Cómo Secureframe puede ayudarle a conseguir y mantener el cumplimiento de PCI DSS a lo largo del tiempo
PCI DSS continuará evolucionando junto con las nuevas tecnologías, las opciones de pago y las nuevas amenazas.
Secureframe puede ayudar a asegurar que su negocio se mantenga actualizado con la última versión. Con expertos en PCI DSS en el personal, se le alertará sobre cualquier actualización de la PCI SSC que pueda afectarle. La recopilación automática de evidencias de Secureframe también enviará alertas en tiempo real para cualquier no conformidad, para que pueda mantener el cumplimiento con PCI DSS con menos estrés para su equipo.
Solicite una demo hoy mismo para ver cómo Secureframe puede ayudarle a lograr y mantener el cumplimiento de PCI con rapidez y facilidad.
Resumen de cambios en PCI DSS 4.0
El PCI SSC realizó cambios significativos en PCI DSS 4.0. El tipo de cambio más notable son los requisitos en evolución, que se refiere a requisitos que se añadieron, actualizaron o eliminaron para asegurar que el estándar esté al día con las amenazas emergentes y las tecnologías, así como con los cambios en la industria de pagos.
A continuación, hemos enumerado todos los nuevos requisitos en PCI DSS 4.0 que se aplican a todas las entidades y solo a los proveedores de servicios. Para ambos grupos, hemos separado los nuevos requisitos que son efectivos inmediatamente para la evaluación v4.0 y aquellos que son efectivos el 31 de marzo de 2025.
Nuevos requisitos para todas las entidades
Los requisitos y subrequisitos a continuación son efectivos inmediatamente para las evaluaciones v4.0 para todas las entidades.
| Requirement 1: Install and Maintain Network Security Controls | |
|---|---|
| 1.1.2 | The roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood. |
| Requirement 2: Apply Secure Configurations to All System Components | |
| 2.1.2 | The roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood. |
| Requirement 3: Protect Stored Account Data | |
| 3.1.2 | The roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood. |
| Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | |
| 4.1.2 | The roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood. |
| Requirement 5: Protect All Systems and Networks from Malicious Software | |
| 5.1.2 | The roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. |
| Requirement 6: Develop and Maintain Secure Systems and Software | |
| 6.1.2 | The roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. |
| Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know | |
| 7.1.2 | The roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.1.2 | The roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. |
| 8.3.4 | Increased the number of invalid authentication attempts before locking out a user ID from six to ten attempts. |
| 8.3.9 | Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days. |
| Requirement 9: Restrict Physical Access to Cardholder Data | |
| 9.1.2 | The roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood. |
| 9.2.4 | New requirement. A sub-requirement has been added to an existing requirement to restrict access to consoles in sensitive areas via locking when not in use. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.1.2 | The roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.1.2 | The roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.1.3 | Added formal acknowledgment by personnel of their responsibilities. |
| 12.3.2 | New requirement for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. |
| 12.5.2 | New requirement to document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. |
| 12.8.5 | Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity. |
Nuevos requisitos con fecha futura para todas las entidades
Los requisitos y subrequisitos a continuación entrarán en vigor el 31 de marzo de 2025 para todas las entidades. Hasta entonces, se consideran mejores prácticas.
| Requirement 3: Protect Stored Account Data | |
|---|---|
| 3.1.3 | New requirement to address former testing procedures that any storage of SAD by issuers is limited to that which is needed for a legitimate issuing business need and is secured. |
| 3.2.1 | A sub-requirement has been added to an existing requirement to address SAD stored prior to completion of authorization through implementation of data retention and disposal policies, procedures, and processes. |
| 3.3.2 | New requirement to encrypt SAD that is stored electronically prior to completion of authorization. |
| 3.4.2 | New requirement for technical controls to prevent copy and/or relocation of PAN when using remote-access technologies. Expanded from former Requirement 12.3.10. |
| 3.5.1.1 | New requirement for keyed cryptographic hashes when hashing is used to render PAN unreadable. |
| 3.5.1.2 | New requirement that disk-level or partition-level encryption is used only to render PAN unreadable on removable electronic media or, if used on non-removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement 3.5.1. |
| Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | |
| 4.2.1 | New requirement. A sub-requirement has been added to an existing requirement to confirm certificates used for PAN transmissions over open, public networks are valid and not expired or revoked. |
| 4.2.1.1 | New requirement to maintain an inventory of trusted keys and certificates. |
| Requirement 5: Protect All Systems and Networks from Malicious Software | |
| 5.2.3.1 | New requirement to define the frequency of periodic evaluations of system components not at risk for malware in the entity’s targeted risk analysis. |
| 5.3.2.1 | New requirement to define the frequency of periodic malware scans in the entity’s targeted risk analysis. |
| 5.3.3 | New requirement for a malware solution for removable electronic media. |
| 5.4.1 | New requirement to detect and protect personnel against phishing attacks. |
| Requirement 6: Develop and Maintain Secure Systems and Software | |
| 6.3.2 | New requirement to maintain an inventory of bespoke and custom software. |
| 6.4.2 | New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods. |
| 6.4.3 | New requirement for management of all payment page scripts that are loaded and executed in the consumer’s browser. |
| Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know | |
| 7.2.4 | New requirement for review of all user accounts and related access privileges. |
| 7.2.5 | New requirement for assignment and management of all application and system accounts and related access privileges. |
| 7.2.5.1 | New requirement for review of all access by application and system accounts and related access privileges. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.3.6 | New requirement to increase password length from a minimum length of seven characters to minimum length of 12 characters (or if the system does not support 12 characters, a minimum length of eight characters). Clarified that until 31 March 2025, passwords must be a minimum length of at least seven characters in accordance with v3.2.1 Requirement 8.2.3. Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. |
| 8.4.2 | New requirement to implement multi-factor authentication (MFA) for all access into the CDE. |
| 8.5.1 | New requirement for secure implementation of multi-factor authentication systems. |
| 8.6.1 | New requirement for management of system or application accounts that can be used for interactive login. |
| 8.6.2 | New requirement for not hard-coding passwords/passphrases into files or scripts for any application and system accounts that can be used for interactive login. |
| 8.6.3 | New requirement for protecting passwords/passphrases for application and system accounts against misuse. |
| Requirement 9: Restrict Physical Access to Cardholder Data | |
| 9.5.1.2.1 | New requirement to define the frequency of periodic POI device inspections based on the entity’s targeted risk analysis. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.4.1.1 | New requirement for the use of automated mechanisms to perform audit log reviews. |
| 10.4.2.1 | New requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) |
| 10.7.2 | New requirement for all entities to detect, alert, and promptly address failures of critical security control systems. This requirement applies to all entities – it includes two additional critical security controls not included in Requirement 10.7.1 for third-party service providers. |
| 10.7.3 | New requirement to respond promptly to failures of any critical security controls. For service providers: this is a current PCI DSS v3.2.1 requirement. For all other (non-service provider) entities: this is a new requirement. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.3.1.1 | New requirement to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans. |
| 11.3.1.2 | New requirement to perform internal vulnerability scans via authenticated scanning. |
| 11.6.1 | New requirement to deploy a change-and-tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.3.1 | New requirement to perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it is performed. |
| 12.3.3 | New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months. |
| 12.3.4 | New requirement to review hardware and software technologies in use at least once every 12 months. |
| 12.6.2 | New requirement to review and update (as needed) the security awareness program at least once every 12 months. |
| 12.6.3.1 | New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE. |
| 12.6.3.2 | New requirement for security awareness training to include awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1. |
| 12.10.4.1 | New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. |
| 12.10.5 | Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following: Detection of unauthorized wireless access points (former 11.1.2). Change-detection mechanism for critical files (former 11.5.1). New requirement. A sub-requirement has been added to an existing requirement for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1). |
| 12.10.7 | New requirement for incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected. |
Nuevos requisitos solo para proveedores de servicios
Los requisitos y subrequisitos a continuación son efectivos inmediatamente para las evaluaciones v4.0 solo para proveedores de servicios.
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
|---|---|
| 12.9.2 | New requirement to support customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. |
Nuevos requisitos con fecha futura solo para proveedores de servicios
Los requisitos y subrequisitos a continuación entrarán en vigor el 31 de marzo de 2025 solo para los proveedores de servicios. Hasta entonces, se consideran buenas prácticas.
| Requirement 3: Protect Stored Account Data | |
|---|---|
| 3.6.1.1 | New requirement. A sub-requirement has been added to an existing requirement to maintain a documented description of the cryptographic architecture that includes prevention of the use of the same cryptographic keys in production and test environments. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.3.10.1 | New requirement - if passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.7.2 | New requirement to detect, alert, and promptly address failures of critical security control systems. It will supersede requirement 10.7.1 for service providers on March 31, 2025. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.4.7 | New requirement for multi-tenant service providers to support their customers for external penetration testing. |
| 11.5.1.1 | New requirement to use intrusion-detection and or intrusion-prevention techniques to detect, alert on/prevent, and address covert malware communication channels. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.5.2.1 | New requirement for service providers to document and confirm PCI DSS scope at least once every six months and upon significant change to the in-scope environment. |
| 12.5.3 | New requirement for service providers for a documented review of the impact to PCI DSS scope and applicability of controls upon significant changes to organizational structure. |
Preguntas Frecuentes
¿Se ha lanzado PCI DSS 4.0?
Sí, PCI DSS 4.0 se lanzó el 31 de marzo de 2022.
¿Cuántos requisitos aplicables inmediatamente hay en PCI DSS v4.0?
La versión 4.0 de PCI DSS entrará en vigor el 31 de marzo de 2024 y tiene 64 nuevos requisitos.
¿Necesitamos implementar PCI DSS 4.0 ahora?
Las organizaciones que procesan, almacenan, transmiten o impactan la seguridad de los datos del titular de la tarjeta deben cumplir con el Estándar de Seguridad de Datos PCI 4.0 antes del 31 de marzo de 2024. También deberán adoptar los requisitos que se han identificado como de fecha futura en la versión 4.0 antes del 31 de marzo de 2025. Dado que no cumplir con esta fecha límite puede resultar en multas, sanciones y otras consecuencias, las organizaciones deben revisar los cambios en la versión 4.0, implementar nuevos controles para cumplir con los requisitos actualizados y nuevos en la versión 4.0, actualizar sus plantillas y formularios de informes y comenzar a implementar los requisitos de seguridad de fecha futura lo antes posible.
¿Cuáles son los cambios de 3.2.1 a 4.0 en PCI DSS?
Los principales cambios de PCI DSS 3.2.1 a 4.0 se centran en satisfacer las necesidades cambiantes de la industria de tarjetas de crédito y de pago y en las nuevas tecnologías, promoviendo la seguridad continua, permitiendo la flexibilidad y mejorando la validación. Para lograr estos objetivos, PCI 4.0:
- tiene requisitos actualizados o nuevos relacionados con la autenticación multifactor, contraseñas, concienciación sobre seguridad y comercio electrónico
- tiene nuevos requisitos para la responsabilidad y confirmación anual del alcance de PCI DSS
- permite que las organizaciones adopten un enfoque personalizado para cumplir con los estrictos requisitos de PCI DSS
- mejora los informes de evaluación de PCI DSS y permite que las organizaciones realicen evaluaciones parciales