PCI DSS is an information security standard for organizations that handle branded credit cards from the major card schemes. You can check a general post about PCI DSS on this link.
As the standard is updated regularly, there are different versions of this standard.
This post summarizes the differences between PCI DSS 3.2.1 and 4.0. It is not intended as a through analysis of the topic, but as a quick overview.
PCI DSS 3.2.1 and 4.0 Key Dates
PCI DSS 3.2.1 was issued on May 2018. PCI DSS audits with this version are valid until 31 March 2024, two years after its successor (PCI DSS 4.0) was published.
PCI DSS 4.0 was issued on 31 March 2022.
The transition period spans from March 2022 to 31 March 2024, as it is the time while PCI DSS 3.2.1 and 4.0 exist.
In addition to the transition period, 31 March 2025 is the deadline to phase in new requirements that are initially identified as best practices in v4.0.
Differences between PCI DSS 3.2.1 and 4.0
Below you can find a brief overview of the new requirements, point by point.
X.1.2. Roles and responsibilities must be defined (in 3.2.1 there was only that known) (in previous version, it was required that the team was familiars with roles and responsibilities).
As a suggestion, it can be implemented through a RASCI matrix for each role and task mentioned in PCI DSS requirements.
12.5.2. Scope must be documented and updated annually.
It must be specifically defined through inventories, etc.
12.9.2. Service providers must support requirement compliance. [applies only to service providers]
3.2.1. All authentication data can be stored, as long as they are necessary
3.3.2. Sensitive Authentication Data (SAD) must be solidly encrypted.
3.3.3. It is a mix of 3.2.1. and 3.3.2 [applies only to Service providers]
3.5.1.1. Simple hash or salted hashes are no longer required. HMAC (hash message authentication code) must be used. Some NIST SP 800 standards (107r1, 38B and 38D) are specified.
3.5.1.2. Non-SAD data that can be stored externally on removable media (USB drives, DVDs, etc.) or non-removable media (backup tapes, internal disks).
3.6.1.1. [applies only to Service providers] Avoid using same cryptographic keys on production and test environemnts
4.2.1. Certificates used to protect PAN must be valid and up-to-date
4.2.1.1. Keep and inventory of all passwords and certificates used to protect PAN
5.3.3. When using removable media, antivirus must be triggered as soon as it is connected or all the time while USB is connected
5.4.1. Controls to protect from phising must be implemented
6.3.2. Inventory of all bespoken software
6.4.2. All public applications needs an annual code review and a WAF (web application firewall)
6.4.3. All scripts run in navigator must be reviewed and listed in an inventory
7.2.4. All acconts must be reviewed on a semiannual basis
7.2.5. System accounts (in opposition to user accounts) have specific requirements
8.3.6. Password requirements: alphanumerical, and length of 12 characters or 8 when it is not technically pheasible
8.3.10.1. [applies only to service providers] Change password each 90 days
8.4.2. All users accessing to CDE (cardholder data environment) must use MFA (multi factor authenticatoin)
8.6.2. Passwords cannot be stored on unsafe files
8.6.3. Passwords must be securely protected
9.5.1.2.1. Risk analysis must be applied to POI devices
10.4.1.1. An automatic tool to analyze logs is required
It means that a SIEM must be used.
10.4.2.1. The frequency of log review depends on risk analysis
An inventory of assets that require risk analysis is convenient
10.7.2. and 10.7.3. All control system must be monitored and should have implemented alerts. Previously, this requirement was only required for serivce providers
11.3.1.1. Vulnerabilities below high and critical must be solved in 90 days, and they must be reviewed
11.3.1.2. Vulnerability scans must be authenticated
11.4.7. [applies only to service providers] Service providers providers must facilitate external pentesting
11.5.1.1. [applies only to service providers] Prevent or detect covered channels
11.6.1. Monitor changes using HTTP headers
12.3.1. Details about what risk analysis content
12.3.3. Encryption algorithms must be reviewed annually.
12.3.4. Hardware and software technologies must be reviewed annually
12.5.2.1.and 12.5.2.2. [applies only to service providers] scope must be reviewed semiannualy
12.6.2. Awaraness program must be reviewed annualy
12.6.3.1. and 12.6.3.2. Training related to threats and vulnerabilities
12.10.4.1. Staff skills is proportional to result of risk analysis
12.10.5. Modification detection alert must be part of incident response processes
12.10.7. Incident response documented when PAN is not stored where expected
A1.1.1. Isolates provider and customer enviroments
A1.1.4. Monitor isolation in pentests
A1.2.3. Customer notification of incidents
A3.3.1 Automatic review of audit record and automatic code reviews must be incorporated into system monitoring
You might be also interested in…
External references
- Lauren Holloway; “Countdown to PCI DSS v4.0“, PCI Security Standards Council
- Javier Roberto Amaya Madrid; “Nuevos controles en PCI DSS 4.0“; ISecAuditors
- cristina; “Novedades PCI DSS v4.0 “; A2Secure
[…] Differences between PCI DSS 3.2.1 and 4.0 […]