Differences between PCI DSS 3.2.1 and 4.0

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] 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. Non-SAD data that can be stored externally on removable media (USB drives, DVDs, etc.) or non-removable media (backup tapes, internal disks). [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 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 [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 Risk analysis must be applied to POI devices An automatic tool to analyze logs is required

It means that a SIEM must be used. 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 Vulnerabilities below high and critical must be solved in 90 days, and they must be reviewed Vulnerability scans must be authenticated

11.4.7. [applies only to service providers] Service providers providers must facilitate external pentesting [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 [applies only to service providers] scope must be reviewed semiannualy

12.6.2. Awaraness program must be reviewed annualy and Training related to threats and vulnerabilities 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

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *