PCI DSS v4.0 – What you need to know

Background

The Payment Card Industry Data Security Standard (PCI DSS) provides a baseline of technical and operational requirements designed to secure payment card data and encourage global adoption of consistent data security measures.

In March 2022 the PCI Security Standards Council published the latest release of the PCI Data Security Standard v4.0. The standard has been reviewed and revised following engagement and feedback with the global payments industry. Over 6000 items of feedback were received during the request for comment periods in the revision period and over 200 companies have provided input into the latest revision.

The revision process focused on the following four key goals:

 Who does PCI DSS apply to?

PCI DSS requirements can be applied to any organisation where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and those organisations with environments that can impact the security of the Cardholder Data Environment (CDE).

Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Cardholder Data includes:

• Primary Account Number (PAN)
• Cardholder Name
• Expiration Date
• Service Code

Sensitive Authentication Data includes:

• Full track data (magnetic-stripe data or equivalent on a chip)
• Card verification code
• PINs/PIN blocks

What are the requirements?

Why was the standard updated?

The previous release (v3.2.1) was published in May 2018. Since then, complexity regarding securing payment card data has increased due to the adoption of new technologies such as the use of cloud environments. The standard has been updated in response to these changing circumstances and the need to maintain and promote best practice across the payment card industry.

In undertaking the revision, the Council has identified the following change types below:

• Evolving requirements – Changes to ensure that the standard is up to date with emerging threats and technologies, and changes in the payment industry. Examples include new or modified requirements or testing procedures, or the removal of a requirement.
• Clarification or guidance – Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
• Structure or format – Reorganisation of content, including combining, separating, and renumbering of requirements to align content.

Why are the latest changes important?

• Security practices must evolve as the threats to payment data change.
• Criminals never sleep! – Ongoing security is crucial to protect payment data.
• Increased flexibility allows more options to achieve a requirement’s objective and supports payment technology innovation.
• Clear validation and reporting options support transparency and granularity.

What has changed In V4.0?

The good news is that there are no new technical requirements that need to be addressed immediately for v4.0, however there are a few administrative requirements that organisations should already be doing that have been formalised.

In total there are 64 changes. Of these 64, 13 become requirements on the release of v4.0 and specifically relate to:

• The definition and communication of roles and responsibilities for performing activities.
• A targeted risk analysis should be performed for each PCI DSS requirement that is met using the newly introduced customized approach.
• The organisation is required to document their CDE and payment flows, the PCI DSS scope being documented and confirmed at least once every 12 months.
• Third Party Service Providers (TPSP’s) must support customers’ requests to provide PCI DSS compliance status and information about PCI DSS requirements that are the responsibility of the TPSP.

The remaining 51 changes are required to be implemented by the 31st March 2025.

Summarised below are the key changes based on alignment with the goals stated above:

Goal – Continue to meet the security needs of the payments industry.

Examples of changed requirements:

• Expanded multi-factor authentication (MFA) requirements at the enterprise level.
  • Revision of MFA requirements for secure implementation in addition to the existing requirements for remote access from outside the entities network.
  • MFA required for all access to Card Data Environment (CDE) vs administrative access to CDE previously.

• Updated password requirements at the enterprise level:
  • More stringent password requirements (length increasing from 7 to 12 characters, no hard-coding in the files or scripts) and change every 90 days if no MFA is applied.
  • Bi-annual review of all user accounts and related access privileges.

• New e-commerce and phishing requirements to address ongoing threats.
  • Detect and protect staff against phishing attacks through use of automated mechanisms for attack detection and awareness training for employees.
  • Daily log reviews by use of automated mechanisms vs the option of manual reviews previously.
  • Authenticated scanning for internal vulnerability scans.
  • Addressing covert malware communication channels by use of intrusion detection/prevention techniques.

Goal – Promote security as a continuous process.

Examples of changed requirements:

• Addition of clearly assigned roles and responsibilities to be documented, assigned and understood for each major requirement.
• Additional guidance to help people better understand how to implement and maintain security.
• New flexible reporting options to highlight areas for improvement and provide more transparency for report reviewers.

Goal – Increase flexibility for organisations using different methods to achieve security objectives.

Examples of changed requirements:

• Allowance of group, shared, and generic accounts (as long as their use is managed).
• Targeted risk analyses empower organisations to establish frequencies for performing certain activities.
  • More thorough, specific and targeted risk assessments.

• Customised approach. – This is a new method to implement and validate PCI DSS requirements and provides another option for organisations using innovative methods to achieve security objectives based on the objectives of each PCI DSS requirement.

It is important to stress that the customised approach is not necessarily an easy alternative to addressing the stated criteria in PCI DSS. This approach will require the assessed organisation to work closely together with the Qualified Security Assessor (QSA) to agree upon, and properly document, chosen controls and testing procedures in order to meet the criteria. So, while this adds flexibility there may be incurred additional overhead in threat / risk assessments, documentation, testing etc.

More information on the customised approach is contained in PCI DSS v4.0 in appendix D.

Goal – Enhance validation methods and procedures.

Examples of changed requirements:

• Increased alignment between information reported in a Report on Compliance or Self-Assessment Questionnaire and information summarised in an Attestation of Compliance.
  • The Report on Compliance (RoC) will remain largely the same but it now has two separate parts – the instructions and the report itself. You are now allowed to remove the instructions from the report before sending it to a client.
  • Service Providers will be required to fill in a RoC. They will no longer do Self assessment questionnaires (SAQ’s) but they may complete their own RoC’s without a Qualified Security Assessor (QSA) if they previously were eligible to complete a SAQ.
  • The PCI Council has currently paused the Merchant Assessment Form (MAF) development and will be updating SAQ’s for v4.0. What the future holds for SAQs/MAFs is uncertain at this time.
  • Regular PCI DSS scope confirmation including card data discovery techniques

Implementation timeline

PCI DSS v3.2.1 remains active for two years (to 31^st March 2024) after the publication of v4.0. This overlap provides organisations who hold PCI DSS certification time to become familiar with the new version, and plan to implement the changes needed.

As stated, with this new release, there are 51 future-dated requirements which will only come into effect after the 31st March 2025 and, until then, will only be considered best practice. As assessor training is not taking place before June 2022, this gives organisations ample time to prepare for and to implement the changes.

More information on implementing the requirements of PCI DSS v4.0 can be found here:

• PCI DSS | CyberCX
• CyberCX PCI DSS Data Sheet
• CyberCX PCI DSS Essentials Training Data Sheet
• Official PCI Security Standards Council Site – Verify PCI Compliance, Download Data Security and Credit Card Security Standards
• Securing the Future of Payments: PCI SSC Publishes PCI Data Security Standard v4.0 (pcisecuritystandards.org)
• First Look at PCI DSS v4.0 – English Subtitles – YouTube
• PCI-DSS-v4-0-At-A-Glance.pdf (pcisecuritystandards.org)
• PCI DSS v4.0: A Preview of the Standard and Transition Training (pcisecuritystandards.org)
• Countdown to PCI DSS v4.0 (pcisecuritystandards.org)
• PCI DSS v4.0: A Conversation with the Council (pcisecuritystandards.org)

How can CyberCX help?

Get in touch to speak to one of our consultants about the adoption of the PCI DSS V4.0 standard or any of our PCI DSS services.

Get in touch