Quoi de neuf dans PCI DSS 4.0? Les principaux changements que vous devez connaître
Lancé en 2006, le Payment Card Industry Data Security Standard (PCI DSS) est un ensemble de normes de sécurité destiné à garantir que toutes les entreprises qui traitent, stockent, transmettent ou impactent la sécurité des données des titulaires de cartes maintiennent un environnement sécurisé.
Aujourd'hui, la norme évolue pour suivre l'état du commerce électronique et des menaces cybernétiques plus sophistiquées. La dernière évolution de la norme — PCI DSS v4.0 — a été publiée le 31 mars 2022.
Nous comprenons qu'il peut être difficile de suivre les derniers changements des exigences de conformité telles que PCI DSS. C'est pourquoi nous faisons partie de notre mission de tenir nos clients informés de tout changement pouvant affecter leur environnement et de maintenir notre plateforme à jour.
Dans cet article, nous expliquons les changements apportés à PCI DSS et ce qu'ils signifient pour votre organisation.
Qu'est-ce que PCI 4.0 ?
PCI 4.0 est la dernière itération majeure de la norme de l'industrie des cartes de paiement et met en œuvre des changements significatifs dans les exigences, se concentrant davantage sur le maintien de la sécurité continue ainsi que sur l'ajout de nouvelles méthodes pour répondre aux exigences.
L'objectif principal de PCI DSS 4.0 est de continuer à faire évoluer la norme pour répondre aux besoins changeants de l'industrie des cartes de paiement et aux nouvelles technologies mises en œuvre quotidiennement.
Lecture recommandée
Histoire de PCI : Comment la norme est née
Changements PCI DSS 4.0 en un coup d'œil
PCI DSS v4.0 inclut une variété de changements qui visent à atteindre quatre objectifs clés :
- continuer à répondre aux besoins de l'industrie des paiements
- promouvoir la sécurité comme un processus continu
- ajouter de la flexibilité et des méthodes supplémentaires pour maintenir la sécurité des paiements
- améliorer les méthodes et procédures de validation des paiements
Voici un aperçu de ces changements. Vous pouvez trouver un résumé plus détaillé à la fin de l'article de blog.
1. Ajout d'une approche personnalisée pour la mise en œuvre et la validation de PCI DSS
Le changement le plus significatif est la mise en œuvre d'une toute nouvelle méthode pour répondre aux exigences appelée l'approche personnalisée.
L'approche personnalisée offre aux organisations la flexibilité nécessaire pour répondre aux objectifs de sécurité des exigences PCI DSS en utilisant de nouvelles technologies et des contrôles innovants. Cela permet aux organisations de répondre aux exigences strictes de PCI DSS de manière plus personnalisée et flexible.
L'évaluateur validera que les contrôles personnalisés répondent aux exigences de PCI DSS en examinant la documentation de l'approche personnalisée de l'entité (y compris une matrice de contrôles et une analyse de risque ciblée) et en développant une procédure de validation des contrôles.
Il est important de comprendre que les contrôles personnalisés ne sont pas des contrôles compensatoires. Les contrôles compensatoires sont des contrôles d'atténuation requis lorsqu'une organisation est incapable de répondre à une exigence pour une contrainte technique ou commerciale légitime et documentée. Les contrôles personnalisés, en revanche, sont une alternative flexible pour répondre aux exigences strictes.
2. Exigences mises à jour
De plus, il y a eu des améliorations majeures aux exigences de PCI DSS 4.0. Celles-ci incluent :
- Des contrôles d'authentification supplémentaires, y compris des exigences strictes en matière d'authentification multi-facteurs lors de l'accès à l'environnement contenant les données des détenteurs de cartes.
- Des exigences de mot de passe mises à jour, y compris l'augmentation de la longueur requise des mots de passe de 8 caractères à 12.
- La modification des exigences concernant les comptes partagés, de groupe et génériques.
- Des rôles et des responsabilités clairement définis pour chaque exigence.
3. Nouvelles exigences
De nouvelles exigences ont également été mises en place pour prévenir et détecter les menaces nouvelles et persistantes contre l'industrie des paiements, y compris les attaques de phishing, de commerce électronique et de skimming électronique.
4. Rapports d'évaluation PCI DSS améliorés
Enfin, des améliorations ont été apportées au document du questionnaire d'auto-évaluation (SAQ) ainsi qu'au modèle de rapport de conformité (RoC) pour aider les organisations lors de l'auto-attestation et les évaluateurs lors de la documentation des résultats.
Pour une répartition plus détaillée des changements entre PCI DSS 3.2.1 et 4.0, consultez le tableau à la fin de cet article.
Lectures recommandées
Exigences PCI DSS 4.0 : une analyse approfondie des derniers changements et de leur impact sur votre organisation
Quand entre en vigueur le PCI DSS 4.0 ?
La version PCI DSS 4.0 a été publiée le 31 mars 2022 et est en vigueur aujourd'hui. Jusqu'au 31 mars 2024, la version précédente de PCI DSS — v3.2.1 — restera également active pour laisser aux organisations le temps d'adopter la dernière version de la norme. Il y a également des exigences supplémentaires qui ne seront considérées comme bonnes pratiques que jusqu'au 31 mars 2025.
Examinons de plus près le calendrier de mise en œuvre de PCI DSS 4.0 ci-dessous.
Source : site web de PCI SSC
Période de transition de PCI DSS v3.2.1 à v4.0
PCI DSS v3.2.1 restera actif de mars 2022 jusqu'au 31 mars 2024. Ces deux années après la publication de la version 4.0 sont destinées à fournir aux organisations suffisamment de temps pour examiner les changements de la version 4.0, mettre à jour leurs modèles et formulaires de rapport, et mettre en œuvre de nouveaux contrôles pour répondre aux exigences mises à jour de la version 4.0.
Pendant cette période de transition, l'environnement de données des titulaires de carte (CDE) d'une organisation peut être évalué en utilisant PCI DSS v3.2.1 ou v4.0.
Le 31 mars 2024, la version 3.2.1 du PCI DSS sera retirée et la version 4.0 deviendra la seule version active de la nouvelle norme.
Mise en œuvre des exigences datées à venir dans PCI DSS 4.0
Les organisations disposeront d'une année supplémentaire après le retrait de la version 3.2.1 pour adopter les exigences identifiées comme datées à venir dans la version 4.0.
Avant le 31 mars 2025, les organisations ne sont pas tenues de valider ces nouvelles exigences. Cependant, si les organisations ont mis en place des contrôles pour répondre aux nouvelles exigences, elles sont encouragées à les faire évaluer plus tôt.
Après le 31 mars 2025, ces exigences datées à venir entrent en vigueur et doivent être pleinement prises en compte dans le cadre d'une évaluation PCI DSS.
Que signifient ces changements pour les organisations déjà certifiées PCI?
En réponse aux changements apportés par la version 4.0 du PCI DSS, les organisations déjà certifiées PCI devraient commencer par faire des recherches. Les organisations devraient examiner les changements dans le document officiel PCI DSS 4.0 sur le site Web du Conseil des normes de sécurité PCI (PCI SSC) pour voir quelles étapes elles devraient suivre afin de se préparer à la mise en œuvre de la version 4.0 en mars 2024.
Les organisations cherchant des conseils concernant les changements qu'elles devraient apporter peuvent contacter leur évaluateur de sécurité qualifié PCI DSS ou un responsable de la conformité de Secureframe. Un responsable de la conformité de Secureframe vous aidera à comprendre les nouvelles exigences, les modifications apportées aux exigences actuelles et comment vous pouvez mettre en œuvre des contrôles au sein de votre environnement afin de respecter les changements de la version 4.0.
Que signifient ces changements pour les organisations qui poursuivent pour la première fois la certification PCI?
Les organisations poursuivant le PCI DSS devraient adopter une approche similaire avec la version 4.0 qu'elles auraient adoptée avec la version 3.2.1.
Commencez par contacter un responsable de la conformité de Secureframe pour vous aider à déterminer la portée de votre service et de votre environnement. Cela vous aidera à comprendre quelles exigences vous devez satisfaire. Ensuite, utilisez la plateforme Secureframe pour compléter les tâches de la plateforme et remédier aux tests automatisés avec le soutien de nos responsables de la conformité. Enfin, sélectionnez l'un de nos QSA partenaires pour effectuer les travaux de terrain directement sur la plateforme.
Lectures recommandées
Accélérez la conformité PCI DSS avec Secureframe
Comment Secureframe peut vous aider à satisfaire aux exigences de PCI DSS 4.0
La conformité à PCI DSS 4.0 sera requise à partir du 31 mars 2024. Si vous ne savez pas comment répondre aux évolutions des exigences, Secureframe peut vous aider.
Utilisez le tableau ci-dessous pour voir les changements d'exigences de PCI 4.0 et comment Secureframe aide les clients à les satisfaire.
| 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. |
Comment Secureframe peut vous aider à obtenir et maintenir la conformité avec PCI DSS dans le temps
PCI DSS continuera d'évoluer avec les nouvelles technologies, options de paiement et nouvelles menaces.
Secureframe peut aider à garantir que votre entreprise reste à jour avec la dernière version. Avec des experts PCI DSS en interne, vous serez alerté de toute mise à jour du PCI SSC qui pourrait vous affecter. La collecte automatique de preuves de Secureframe enverra aussi des alertes en temps réel pour toute non-conformité, vous permettant ainsi de maintenir la conformité à PCI DSS avec moins de stress pour votre équipe.
Demandez une démonstration aujourd'hui pour voir comment Secureframe peut vous aider à atteindre et à maintenir la conformité PCI avec rapidité et facilité.
Résumé des changements de PCI DSS 4.0
Le PCI SSC a apporté des changements significatifs à PCI DSS 4.0. Le type de changement le plus notable concerne les exigences évolutives, ce qui fait référence aux exigences ajoutées, mises à jour ou supprimées pour s'assurer que la norme est à jour avec les nouvelles menaces et technologies émergentes ainsi que les changements dans le secteur des paiements.
Ci-dessous, nous avons listé toutes les nouvelles exigences de PCI DSS 4.0 qui s'appliquent à toutes les entités et uniquement aux prestataires de services. Pour les deux groupes, nous avons séparé les nouvelles exigences qui sont immédiatement effectives pour l'évaluation de la version 4.0 et celles qui seront effectives le 31 mars 2025.
Nouvelles exigences pour toutes les entités
Les exigences et sous-exigences ci-dessous sont immédiatement effectives pour les évaluations de la version 4.0 pour toutes les entités.
| 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. |
Nouvelles exigences datées dans le futur pour toutes les entités
Les exigences et sous-exigences ci-dessous entreront en vigueur le 31 mars 2025 pour toutes les entités. D'ici là, elles sont considérées comme de bonnes pratiques.
| 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. |
Nouvelles exigences pour les prestataires de services uniquement
Les exigences et sous-exigences ci-dessous sont immédiatement effectives pour les évaluations de la version 4.0 pour les prestataires de services uniquement.
| 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. |
Nouvelles exigences datées dans le futur pour les prestataires de services uniquement
Les exigences et sous-exigences ci-dessous entreront en vigueur le 31 mars 2025 pour les prestataires de services uniquement. D'ici là, elles sont considérées comme des meilleures pratiques.
| 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. |
FAQ
La version PCI DSS 4.0 a-t-elle été publiée?
Oui, PCI DSS 4.0 a été publiée le 31 mars 2022.
Combien y a-t-il de exigences immédiatement applicables dans PCI DSS v4.0 ?
La version 4.0 de PCI DSS entrera en vigueur le 31 mars 2024 et comprend 64 nouvelles exigences.
Devons-nous mettre en œuvre PCI DSS 4.0 maintenant?
Les organisations qui traitent, stockent, transmettent ou influencent la sécurité des données des titulaires de carte doivent se conformer à la norme de sécurité des données PCI 4.0 d'ici le 31 mars 2024. Elles devront également adopter les exigences identifiées comme ayant une date de mise en œuvre future dans la version 4.0 d'ici le 31 mars 2025. Étant donné que le non-respect de cette date limite peut entraîner des amendes, des pénalités et d'autres conséquences, les organisations doivent examiner les changements de la version 4.0, mettre en œuvre de nouveaux contrôles pour répondre aux exigences mises à jour et nouvelles de la version 4.0, mettre à jour leurs modèles et formulaires de rapport et commencer à mettre en œuvre des exigences de sécurité avec date échelonnée dès que possible.
Quels sont les changements de la version 3.2.1 à la version 4.0 dans PCI DSS?
Les principaux changements de PCI DSS 3.2.1 à 4.0 se concentrent sur la satisfaction des besoins changeants de l'industrie des cartes de crédit et de paiement ainsi que des nouvelles technologies, la promotion de la sécurité continue, permettant une flexibilité et améliorant la validation. Pour atteindre ces objectifs, PCI 4.0 :
- a mis à jour ou introduit de nouvelles exigences liées à l'authentification multi-facteurs, aux mots de passe, à la sensibilisation à la sécurité et au commerce électronique
- a de nouvelles exigences pour la responsabilité et la confirmation annuelle de la portée de PCI DSS
- permet aux organisations de prendre une approche personnalisée pour satisfaire aux exigences strictes de PCI DSS
- a amélioré les rapports d'évaluation PCI DSS et permet aux organisations de réaliser des évaluations partielles.