Share this article
Summary Overview Of This Article:
- The current Standard (v3.2.1) will expire on March 31, 2024.
- 64 new requirements – 13 requirements effective immediately and 51 requirements to be complied with by 31st March 2025.
- 12 Principal PCI DSS requirement areas remain the same.
- Introduction of the Customised Approach - Flexibility in meeting individual security objectives.
- Requires entities to clearly assign roles and responsibilities for each PCI DSS Requirement.
- Enhanced Risk Management & Governance and oversight are expected from entities.
The PCI DSS standard has evolved from the time version 1.0 was released in December 2004 through to v4.0, released in March 2022. If we look at the evolution of the PCI DSS standard from version 1.0 to version 3.2.1, it is evident that it was developed to suit organisations of varying size and complexity, those who are agile in embracing newer technologies and those organisations that operate a traditional IT environment. The standard always catered to this objective of a one-size-fits-all approach. The main reason is, that no matter the type of organisation, the standard is always applied to entities that store, process, and/or transmit cardholder data. If you accept or process payment cards, PCI DSS applies to you.
PCI DSS v4.0 was released by the PCI Standards Council in March 2022. Reviewing the changes in the new version, it is evident that the PCI Standards Council has again anchored the standard based on the objective that all entities that store, process, or transmit cardholder data must comply with the standard. For organisations that are currently complying with or are familiar with the current standard, it would be comforting to know that the Twelve (12) core PCI DSS requirements remain the same.
The new standard will benefit organisations in better understanding the requirements as there are a large number of upgrades to wording, explanation, definition, guidance and/or instructions. The structure of the content is reorganised, including combining separation and renumbering of requirements to align content. However, the most glaring benefit of the new standard is for organisations that were traditionally using compensating controls, as a temporary measure to meet the PCI DSS requirements, to use the Customised Approach.
Customised Approach - New Method To Implement And Validate PCI DSS Requirements
PCI DSS v4.0 addresses this scenario by introducing a ‘Customised Approach’ where entities are allowed greater flexibility to show how their current security controls meet PCI DSS objectives.
What is the Customised Approach?
The Customised Approach enables utilising specialised testing procedures, that are developed by the Qualified Security Assessor (QSA) and agreed upon by the entity being audited. In reality, this will require performing a detailed initial assessment of the entity’s environment and a review of the entity’s risk assessment data to develop the customised audit steps. As per the PCI Council, customised validation will not require a justification – business or technical – for adhering to the requirements using compensating controls as the requirements will be outcome-based as envisaged in the new PCI DSS v4.0.
The PCI Council has also included a ‘Defined Approach’, which is nothing but the traditional method of implementing and validating against PCI DSS using requirements and test procedures defined within the standards. Depending on the maturity of the risk management practices, organisations are free to choose which approach to take. One caveat associated with the Customised Approach is that it is applicable to a majority of requirements, but not all of them.
Evolving Standards To Meet Evolving Threats
The last major version of the PCI DSS standard was version 3.0, which was published in 2014. There have been many changes to the IT landscape since then, especially with the large-scale adoption of the cloud environment to host critical systems, including payment systems. With the adoption of the cloud and mutation of various security technologies from traditional capabilities to protect against evolving threats, the standard has updated various terminologies used in the previous standard, and this constitutes a majority of the changes in version 4.0. However, there are a few evolving requirements, such as implementing multi-factor authentication (MFA) for all access to the Cardholder Data Environment (CDE) and defining roles and responsibilities in the form of a RACI matrix for all personnel who are involved in performing activities addressing each of the 12 requirements included within the standard.
The following are some of the key changes that are made in v4.0. The complete list of key changes and the evolving requirements can be accessed at the PCI Standards Council website:
- Clear definition and documentation of roles and responsibilities that are assigned within the organisation for performing activities in Requirements 1-12.
- Requirements associated with stored Primary Account Number (PAN) and Sensitive Authentication Data (SAD) such as updating cryptographic architecture, encrypting SAD and PAN while it is stored, and the need to develop data retention and disposal policies.
- Need to maintain inventory of entity’s trusted keys and certificates, cryptographic cypher suites and protocols.
- Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis. Some examples are:
- Periodic evaluations of system components identified as not at risk for malware;
- Anti-malware scans;
- Review of all access using application and system accounts;
- Periodic POI device inspections;
- Periodic logs review;
- Addressing vulnerabilities that are not ranked as high or critical risk; and
- Frequency of periodic training for incident response personnel.
- A new requirement is to implement controls to protect personnel against phishing attacks.
- An automated technical solution for public-facing web applications is mandatory for organisations from the 31st of March 2025
- Review access privileges for user and system accounts.
- Manual log reviews will not be an option for reviewing logs from March 31, 2025. Targeted risk analysis to determine the log review frequency.
- Requirement to detect, alert and respond to failures of critical security control systems
- A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customised approach
- Internal vulnerability scans need to be performed via authenticated scanning.
- A change-and-tamper-detection mechanism is deployed for payment pages
- Requirements around security awareness training such as:
- The awareness program to be reviewed every 12 months and updated as needed
- Include phishing and related attacks and social engineering-related content
- Should cover awareness about the acceptable use of end-user technologies.
- Multi-tenant service providers should :
- Confirm access to and from the customer environment is logically separated
- Confirm the effectiveness of logical separation once every 6 months via penetration testing
- Implement a process for reporting and addressing suspected or confirmed security incidents and vulnerabilities.
Source: PCI DSS v4.0: Anticipated Timelines and Latest Updates, PCI Standards Security Council
PCI DSS v3.2.1 will remain active for two years after v4.0 is published. This transition period, from March 2022 until 31 March 2024, provides organisations with time to become familiar with the changes in v4.0, update their reporting templates and forms, and plan for and implement changes to meet updated requirements.As of 31 March 2024, PCI DSS v3.2.1 will be retired and v4.0 will become the only active version of the standard.
How To Be Prepared
Organisations that are required to maintain PCI DSS compliance should prepare to undertake the following at a minimum:
- Implement additional requirements that are new in PCI DSS V4.0. Engage a QSA if the organisation requires assistance with interpreting and implementing new requirements in the standard.
- Identify whether they would use a Customised Approach to meet any PCI DSS requirements.
- Prepare documentation defining the customised implementation of any of the PCI DSS requirements.
- Engage with a QSA to agree on the steps for evaluating the controls that are implemented based on the customised approach.
Speak with a Tesserent
Tesserent is a full-service cybersecurity and secure cloud services provider, partnering with clients from all industries and all levels of government. Let’s talk.