Was ist neu in PCI DSS 4.0? Die wichtigsten Änderungen, die man kennen sollte
Der 2006 eingeführte Datensicherheitsstandard der Zahlungsverkehrsindustrie (PCI DSS) ist eine Reihe von Sicherheitsstandards, die sicherstellen sollen, dass alle Unternehmen, die Kartendaten verarbeiten, speichern, übertragen oder deren Sicherheit beeinträchtigen, eine sichere Umgebung aufrechterhalten.
Heute entwickelt sich der Standard weiter, um dem Stand des E-Commerce und den zunehmend ausgeklügelten Cyber-Bedrohungen gerecht zu werden. Die neueste Entwicklung des Standards — PCI DSS v4.0 — wurde am 31. März 2022 veröffentlicht.
Wir verstehen, dass es schwierig sein kann, mit den neuesten Entwicklungen der Konformitätsanforderungen wie dem PCI DSS Schritt zu halten. Deshalb ist es Teil unserer Mission, unsere Kunden über alle Änderungen, die ihre Umgebung betreffen könnten, auf dem Laufenden zu halten und unsere Plattform aktuell zu halten.
In diesem Artikel erklären wir die Änderungen am PCI DSS und was sie für Ihr Unternehmen bedeuten.
Was ist PCI 4.0?
PCI 4.0 ist die neueste große Iteration des Standards der Zahlungsverkehrsindustrie und bringt signifikante Änderungen an den Anforderungen mit sich. Dabei wird stärker auf die kontinuierliche Aufrechterhaltung der Sicherheit sowie auf neue Methoden zur Erfüllung der Anforderungen gesetzt.
Das Hauptziel von PCI DSS 4.0 ist es, den Standard weiterzuentwickeln, um den sich ändernden Bedürfnissen der Zahlungsverkehrsbranche und den neuen täglich implementierten Technologien gerecht zu werden.
Empfohlene Lektüre
Geschichte des PCI: Wie der Standard entstand
Die Änderungen von PCI DSS 4.0 auf einen Blick
PCI DSS v4.0 umfasst eine Vielzahl von Änderungen, die vier Hauptziele verfolgen:
- weiterhin die Bedürfnisse der Zahlungsverkehrsindustrie zu erfüllen
- Sicherheit als kontinuierlichen Prozess zu fördern
- flexiblere und zusätzliche Methoden zur Aufrechterhaltung der Zahlungssicherheit hinzuzufügen
- die Methoden und Verfahren zur Zahlungsvalidierung zu verbessern
Hier ist ein Überblick über diese Änderungen. Eine detailliertere Zusammenfassung finden Sie am Ende des Blogeintrags.
1. Hinzufügung eines individuellen Ansatzes zur Umsetzung und Validierung von PCI DSS
Die bedeutendste Änderung ist die Einführung einer völlig neuen Methode zur Erfüllung der Anforderungen, die als individueller Ansatz bezeichnet wird.
Der individuelle Ansatz bietet Organisationen die Flexibilität, die Sicherheitsziele der PCI DSS-Anforderungen mit neuen Technologien und innovativen Kontrollen zu erreichen. Dies ermöglicht es Organisationen, die strengen PCI DSS-Anforderungen auf individuellere und flexiblere Weise zu entsprechen.
Der Prüfer wird validieren, dass die individuellen Kontrollen die PCI DSS-Anforderungen erfüllen, indem er die Dokumentation des individuellen Ansatzes der Organisation (einschließlich einer Kontrollmatrix und einer gezielten Risikoanalyse) überprüft und ein Validierungsverfahren für die Kontrollen erstellt.
Es ist wichtig zu verstehen, dass individuelle Kontrollen keine kompensatorischen Kontrollen sind. Kompensatorische Kontrollen sind Minderungsmaßnahmen, die erforderlich sind, wenn eine Organisation eine Anforderung aufgrund einer legitimen und dokumentierten technischen oder geschäftlichen Einschränkung nicht erfüllen kann. Individuelle Kontrollen hingegen sind eine flexible Alternative zur Erfüllung der strengen Anforderungen.
2. Aktualisierte Anforderungen
Darüber hinaus wurden wesentliche Verbesserungen der Anforderungen in PCI DSS 4.0 vorgenommen. Diese beinhalten:
- Zusätzliche Authentifizierungskontrollen, einschließlich strenger Anforderungen an die Mehrfachauthentifizierung beim Zugriff auf die Karteninhaberdatenumgebung.
- Aktualisierte Passwortanforderungen, einschließlich der Erhöhung der Passwortlänge von 8 auf 12 Zeichen.
- Änderungen der Anforderungen an freigegebene, Gruppen- und generische Konten.
- Klar definierte Rollen und Verantwortlichkeiten für jede Anforderung.
3. Neue Anforderungen
Neue Anforderungen wurden ebenfalls implementiert, um neue und bestehende Bedrohungen für die Zahlungsbranche, einschließlich Phishing, E-Commerce und E-Skimming-Angriffe, zu verhindern und zu erkennen.
4. Verbesserte PCI DSS-Bewertungsberichte
Schließlich wurden Verbesserungen am Selbstbewertungsfragebogen (SAQ) und am Konformitätsbericht (RoC)-Muster vorgenommen, um Organisationen bei der Selbstbestätigung und Prüfer bei der Dokumentation der Ergebnisse zu unterstützen.
Für eine detailliertere Aufschlüsselung der Änderungen zwischen PCI DSS 3.2.1 und 4.0, konsultieren Sie die Tabelle am Ende dieses Artikels.
Empfohlene Lektüre
PCI DSS 4.0 Anforderungen: Ein tiefer Einblick in die neuesten Änderungen und ihre Auswirkungen auf Ihre Organisation
Wann tritt die PCI DSS 4.0 in Kraft?
Der PCI DSS 4.0 wurde am 31. März 2022 veröffentlicht und ist ab heute in Kraft. Bis zum 31. März 2024 bleibt die vorherige Version des PCI DSS - v3.2.1 - ebenfalls in Kraft, um den Organisationen Zeit zu geben, die neueste Version des Standards zu übernehmen. Es gibt auch zusätzliche Anforderungen, die bis zum 31. März 2025 nur als bewährte Praktiken gelten werden.
Lassen Sie uns den Zeitplan für die Implementierung von PCI DSS 4.0 unten näher betrachten.
Quelle: PCI SSC Website
Übergangszeitraum von PCI DSS v3.2.1 zu v4.0
PCI DSS v3.2.1 bleibt von März 2022 bis zum 31. März 2024 in Kraft. Diese zwei Jahre nach der Veröffentlichung von v4.0 sollen den Organisationen ausreichend Zeit geben, die Änderungen in v4.0 zu überprüfen, ihre Berichtsmodelle und -formulare zu aktualisieren und neue Kontrollen umzusetzen, um den aktualisierten Anforderungen in v4.0 zu entsprechen.
Während dieses Übergangszeitraums kann die Karteninhaberdatenumgebung (CDE) einer Organisation entweder mit PCI DSS v3.2.1 oder v4.0 bewertet werden.
Am 31. März 2024 wird der PCI DSS v3.2.1 zurückgezogen und v4.0 wird die einzige aktive Version des neuen Standards.
Umsetzung der zukünftigen Anforderungen in PCI DSS 4.0
Die Organisationen haben ein weiteres Jahr nach dem Rückzug von v3.2.1, um die Anforderungen zu übernehmen, die in v4.0 als zukünftige Anforderungen identifiziert wurden.
Vor dem 31. März 2025 sind die Organisationen nicht verpflichtet, diese neuen Anforderungen zu validieren. Wenn die Organisationen jedoch Kontrollen implementiert haben, um den neuen Anforderungen zu entsprechen, wird empfohlen, diese früher bewerten zu lassen.
Nach dem 31. März 2025 treten diese zukünftigen Anforderungen in Kraft und müssen vollständig im Rahmen einer PCI DSS-Bewertung berücksichtigt werden.
Was bedeuten diese Änderungen für bereits PCI-zertifizierte Organisationen?
Als Reaktion auf die Änderungen der Version 4.0 des PCI DSS sollten bereits PCI-zertifizierte Organisationen zunächst Nachforschungen anstellen. Die Organisationen sollten die Änderungen im offiziellen PCI DSS 4.0 Dokument auf der Website des PCI Security Standards Council (PCI SSC) überprüfen, um zu sehen, welche Schritte sie unternehmen müssen, um sich auf die Implementierung der Version 4.0 im März 2024 vorzubereiten.
Organisationen, die Ratschläge zu den Änderungen suchen, die sie vornehmen sollten, können ihren qualifizierten PCI DSS-Sicherheitsbewerter oder einen Secureframe-Compliance-Beauftragten kontaktieren. Ein Secureframe-Compliance-Beauftragter wird Ihnen helfen zu verstehen, welche neuen Anforderungen es gibt, welche Änderungen an den aktuellen Anforderungen vorgenommen wurden und wie Sie Kontrollen in Ihrer Umgebung implementieren können, um den Änderungen der Version 4.0 zu entsprechen.
Was bedeuten diese Änderungen für Organisationen, die zum ersten Mal eine PCI-Zertifizierung anstreben?
Organisationen, die dem PCI DSS-Standard folgen, sollten einen ähnlichen Ansatz mit Version 4.0 verfolgen, wie sie es mit Version 3.2.1 getan hätten.
Beginnen Sie damit, einen Secureframe-Compliance-Manager zu kontaktieren, um den Umfang Ihres Dienstes und Ihrer Umgebung zu bestimmen. Dies hilft Ihnen zu verstehen, welche Anforderungen Sie erfüllen müssen. Verwenden Sie dann die Secureframe-Plattform, um die Plattformaufgaben zu erledigen und automatisierte Tests mit Unterstützung unserer Compliance-Manager zu beheben. Wählen Sie schließlich einen unserer Partner-QSAs aus, um die Feldarbeit direkt auf der Plattform durchzuführen.
Empfohlene Lektüre
Beschleunigen Sie die PCI-DSS-Konformität mit Secureframe
Wie Secureframe Ihnen helfen kann, die Anforderungen des PCI DSS 4.0 zu erfüllen
Die Konformität mit PCI DSS 4.0 wird ab dem 31. März 2024 obligatorisch sein. Wenn Sie nicht wissen, wie Sie den geänderten Anforderungen gerecht werden, kann Secureframe Ihnen helfen.
Verwenden Sie die folgende Tabelle, um die geänderten Anforderungen des PCI 4.0 und wie Secureframe seine Kunden dabei unterstützt, diese zu erfüllen, nebeneinander zu sehen.
| 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. |
Wie Secureframe Ihnen helfen kann, die PCI-DSS-Konformität im Laufe der Zeit zu erreichen und aufrechtzuerhalten
Der PCI-DSS-Standard wird sich mit neuen Technologien, Zahlungsoptionen und neuen Bedrohungen weiterentwickeln.
Secureframe kann Ihnen helfen sicherzustellen, dass Ihr Unternehmen mit der neuesten Version auf dem Laufenden bleibt. Mit PCI-DSS-Experten im Team werden Sie über alle relevanten Aktualisierungen des PCI SSC informiert. Die automatische Beweiserfassung von Secureframe wird auch Echtzeit-Benachrichtigungen bei Nichteinhaltung senden, sodass Sie die PCI-DSS-Konformität mit weniger Stress für Ihr Team aufrechterhalten können.
Fordern Sie noch heute eine Demo an, um zu sehen, wie Secureframe Ihnen helfen kann, die PCI-Konformität schnell und einfach zu erreichen und aufrechtzuerhalten.
Übersicht der Änderungen des PCI DSS 4.0
Die PCI SSC hat signifikante Änderungen am PCI DSS 4.0-Standard vorgenommen. Die markanteste Änderung ist die Weiterentwicklung der Anforderungen, bei der Anforderungen hinzugefügt, aktualisiert oder entfernt wurden, um sicherzustellen, dass der Standard mit aufkommenden Bedrohungen und Technologien sowie Änderungen in der Zahlungsbranche aktuell bleibt.
Im Folgenden haben wir alle neuen Anforderungen des PCI DSS 4.0 aufgelistet, die für alle Unternehmen und nur für Dienstleister gelten. Für beide Gruppen haben wir die neuen Anforderungen, die sofort für die Version 4.0-Bewertung gelten, und diejenigen, die ab dem 31. März 2025 gelten, getrennt aufgelistet.
Neue Anforderungen für alle Unternehmen
Die unten aufgeführten Anforderungen und Unteranforderungen gelten sofort für Bewertungen der Version 4.0 aller Unternehmen.
| 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. |
Zukünftige neue Anforderungen für alle Einheiten
Die nachstehenden Anforderungen und Unteranforderungen treten am 31. März 2025 für alle Einheiten in Kraft. Bis dahin gelten sie als bewährte Verfahren.
| 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. |
Neue Anforderungen nur für Dienstleister
Die nachstehenden Anforderungen und Unteranforderungen gelten ab sofort für Bewertungen nach Version 4.0 nur für Dienstleister.
| 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. |
Zukünftige neue Anforderungen nur für Dienstleister
Die nachstehenden Anforderungen und Unteranforderungen treten am 31. März 2025 nur für Dienstleister in Kraft. Bis dahin gelten sie als bewährte Verfahren.
| 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
Wurde der PCI DSS 4.0 Standard veröffentlicht?
Ja, der PCI DSS 4.0 Standard wurde am 31. März 2022 veröffentlicht.
Wie viele unmittelbar anwendbare Anforderungen gibt es in PCI DSS v4.0?
Die Version 4.0 des PCI DSS tritt am 31. März 2024 in Kraft und umfasst 64 neue Anforderungen.
Müssen wir den PCI DSS 4.0 Standard jetzt umsetzen?
Organisationen, die Kartendaten verarbeiten, speichern, übertragen oder die Sicherheit dieser Daten beeinflussen, müssen bis zum 31. März 2024 die PCI DSS 4.0 Sicherheitsstandards einhalten. Sie müssen auch die in Version 4.0 als datiert gekennzeichneten Anforderungen bis zum 31. März 2025 übernehmen. Da die Nichteinhaltung dieser Frist zu Strafen, Sanktionen und anderen Konsequenzen führen kann, sollten Organisationen die Änderungen der Version 4.0 prüfen, neue Kontrollen einführen, um die aktualisierten und neuen Anforderungen der Version 4.0 zu erfüllen, ihre Berichtsvorlagen und -formulare aktualisieren und so bald wie möglich mit der Umsetzung der zukünftigen Sicherheitsanforderungen beginnen.
Was sind die Änderungen in PCI DSS zwischen den Versionen 3.2.1 und 4.0?
Die wichtigsten Änderungen im PCI DSS zwischen den Versionen 3.2.1 und 4.0 zielen darauf ab, den sich ändernden Bedürfnissen der Kreditkarten- und Zahlungsbranche sowie neuen Technologien gerecht zu werden, eine kontinuierliche Sicherheit zu fördern, Flexibilität zu ermöglichen und die Validierung zu stärken. Um diese Ziele zu erreichen, umfasst PCI 4.0:
- aktualisierte oder neue Anforderungen im Zusammenhang mit Multi-Faktor-Authentifizierung, Passwörtern, Sicherheitsbewusstsein und E-Commerce
- neue Anforderungen in Bezug auf Verantwortlichkeit und jährliche Bestätigung des PCI DSS-Geltungsbereichs
- Ermöglichung einer personalisierten Herangehensweise für Organisationen zur Erfüllung der strengen PCI DSS-Anforderungen
- verbesserte PCI DSS-Bewertungsberichte und ermöglicht es Organisationen, teilweise Bewertungen durchzuführen