In today’s business landscape, adhering to the Payment Card Industry Data Security Standard (PCI DSS) is essential. As a business owner, have you ever considered how secure your client’s credit card information is? In the modern digital age, safeguarding sensitive data is crucial. Protecting your clients’ card information not only maintains their trust in your business but also helps prevent costly data breaches that can damage your brand.

In this blog, we will explore the changes in the PCI DSS compliance standards. These fundamental guidelines are necessary for protecting cardholder information. We will thoroughly cover each requirement, including regular Vulnerability Assessment and Penetration Testing (VAPT) and firewall configurations. Follow along to ensure your business is on the right path towards PCI DSS compliance

Types of Changes in Requirements of PCI DSS Compliance

Recent updates in the PCI DSS (Payment Card Industry Data Security Standard) compliance requirements necessitate organizations to stay informed and adapt accordingly. The following are the types of changes that have been introduced to ensure enhanced security and protection of cardholder data:

Evolving Requirement

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 testing procedures or the removal of a requirement. Note that there were no changes categorized as “Evolving Requirement” in this
version of PCI DSS.

Classification 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

Reorganization of content, including combining, separating, and renumbering of requirements to align content. 

Overview of Revisions to PCI DSS Introductory Sections

Below are the key changes in requirements made to the introductory sections of PCI DSS from version 4.0 to version 4.0.1:

Section 3: Relationship between PCI DSS and PCI SSC Software Standards

• Revised note to reflect PA-DSS retirement. The PCI Security Standards Council (PCI SSC) will no longer update, revise, or provide support for the PA-DSS standard. The PCI SSF (Software Security Framework) has taken over the role of assessing payment application security within the PCI DSS v4.1 framework and beyond. 
• Updated “Validated Software Vendors” to “Qualified Software Vendors.”

Section 4: Scope of PCI DSS Requirements

• Added a sub-section on handling cardholder data received via unintended channels.
• Clarify the importance of understanding responsibilities between Third-Party Service Providers (TPSPs) and customers.
• Updated references and clarified documentation requirements for TPSPs impacting cardholder data security.

Section 7: Description of Timeframes Used in PCI DSS Requirements

• Clarify the description of Significant Change regarding timeframes used in PCI DSS Requirements. 
• Specified that an initial PCI DSS assessment occurs only when an entity is first assessed against a PCI DSS requirement within a defined timeframe.

Section 8: Approaches for Implementing and Validating PCI DSS

• Updated Customized Approach references to include sample templates on the PCI SSC website.
• Revised Figure 4 and updated “ROC Reporting Template” to “ROC Template.”

Section 14: PCI DSS Versions

• Removed reference to PCI DSS v3.2.1 as it is retired (no longer relevant).
• Clarified that PCI DSS v4.0.1 is the current version.
• Directed questions about previous PCI DSS versions to organizations managing compliance programs.
• Updated Table 6 with v4.0.1 publication date, v4.0 retirement date, and v3.2 information.

Changes in PCI DSS Requirements

To address stakeholder feedback and questions received since the publication of PCI DSS v4.0 in March 2022, the PCI Security Standards Council (PCI SSC) has released a revised version, PCI DSS v4.0.1. This update corrects formatting and typographical errors and clarifies the focus and intent of certain requirements and guidance, without adding or removing any requirements.

To ensure that these changes and clarifications effectively support industry adoption of PCI DSS v4, the PCI SSC Board of Advisors, Global Executive Assessor Roundtable, and Principal Participating Organizations (via the Technology Guidance Group) reviewed and provided feedback on the proposed changes during a Request for Comments (RFC) period from December 2023 to January 2024.

Please note that no new requirements have been introduced. We’ve only provided additional details for the ISA’s convenience.

To learn about all 12 requirements of PCI DSS 4.0, check out our blog post titled “What’s New in PCI DSS Version 4.0? A Complete Guide”.

Requirement 3

Applicability Note for Issuers and SAD Storage:

• Emphasizes that any storage of Sensitive Authentication Data (SAD) must be based on a “legitimate and documented business need”.
• Includes a new description of legitimate business needs.
• Adds good practices for acceptable SAD storage in non-persistent memory.

Clarification on SAD Storage:

Updates the language from “SAD is not retained after authorization” to “SAD is not stored after authorization” for consistency.

Applicability Note for SAD Storage Needs:

• Clarifies the legitimate business need for SAD storage for issuers and companies supporting issuing services.
• Aligns the description of the “authorization process” with the Glossary definition.

Legitimate Issuing Business Need:

• Adds an Applicability Note describing a legitimate issuing business need, aligned with previous notes.
• Removes outdated definitions and further information.

Updates on PAN Data Handling:

• Moves the note on the triviality of reconstructing PAN data from an Applicability Note to Good Practice.
• Updates the Purpose from “The removal of cleartext PAN” to “Rendering PAN unreadable”.
• Adds information on implementing keyed cryptographic hashes as a valid additional control.

Customized Approach for PAN Handling:

• Adds a Customized Approach Objective for flexibility in meeting the requirements.
• Notes the requirement’s applicability to system components generating individual keyed hashes of a PAN for comparison.

Encryption Methods for PAN Handling:

• Adds a Customized Approach Objective for flexibility.
• Provides an Applicability Note on the types of encryption methods applicable to this requirement.
• Specifies how this requirement applies to issuers and those providing issuing services.

Requirement 4

4.2.1

• Move the Applicability Note about receiving cardholder data via an unsolicited channel to a new sub-section in Section 4, Scope of PCI DSS Requirements.
• Remove the Applicability Note sentence that covered self-signed certificates.

4.2.2

Add to Good Practice about the use of Acceptable Use Policies to manage end-user technologies.

Requirement 5

Remove the Applicability Note regarding the automated mechanism to clarify that the requirement does apply to systems providing the mechanism, as PCI DSS generally applies to systems that provide security services.

Requirement 6

6.3.1:

• Clarified that this requirement is in addition to performing vulnerability scans as per Requirements 11.3.1 and 11.3.2.
• Added Good Practice text from PCI DSS v3.2.1 regarding risk rankings identifying high-risk or critical vulnerabilities.
• Updated Good Practice to include multiple sources of vulnerability information in the vulnerability management process.

6.3.3:

• Reverted the requirement language to v3.2.1, applying to patches/updates for critical vulnerabilities and removing “high-security patches/updates.”
• Moved the example of “within three months of release” to Examples.
• Clarified that other applicable security patches/updates should be installed based on the entity’s risk assessment.
• Added Good Practice recommending a targeted risk analysis to determine the frequency of installing other security patches/updates.

6.4.3:

• Clarified the requirement for maintaining an inventory of scripts with written business or technical justification.
• Added Applicability Notes to clarify how the requirement applies to an entity’s and TPSP’s/payment processor’s embedded payment pages/forms.
• Added guidance under Purpose for situations where authorizing scripts before changes/additions is impractical.
• Added Good Practice expecting TPSPs/payment processors to provide evidence of compliance when embedded payment pages/forms are used.

6.5.5:

• Removed Good Practice on minimizing storage of live PANs in pre-production.
• Clarified under Definitions that live PANs are issued by or on behalf of a payment brand and removed wording on their potential use for transactions.

Requirement 8

General:

Updated statement in the Overview and Applicability Notes for several requirements to clarify that certain requirements do not apply to user accounts on point-of-sale terminals with access to only one card number at a time.

8.2.2:

• Changed “account” to “ID” in the requirement and guidance.
• Updated Customized Approach Objective to specify “group, shared, or generic IDs.”

8.3.9:

Clarified that the requirement does not apply to in-scope system components where Multi-Factor Authentication (MFA) is used.

8.4.1:

Moved the recommendation that MFA is a best practice for non-console administrative access to in-scope system components not part of the CDE from an Applicability Note to Good Practice.

8.4.2:

• Clarified that the requirement applies to all “non-console” access into the Cardholder Data Environment (CDE).
• Added an Applicability Note that this requirement does not apply to user accounts authenticated only with phishing-resistant authentication factors.

8.4.3:

• Clarified that the requirement applies to “remote access” rather than “remote network access.”
• Moved bullets about types of remote access included to an Applicability Note.
• Added “third parties” to the testing procedure.

8.5.1:

• Add a definition for a replay attack under Definitions. 
• Add examples of methods to help protect against replay attacks under Examples. 

Requirement 9

General:

Add a statement to the Overview that each entity should identify sensitive areas for their environment to ensure appropriate physical security controls are implemented. 

9.2.1

Add Applicability Note that this requirement does not apply to locations that are publicly 

accessible by consumers (cardholders).

9.3.4

Clarified that the requirement is for “visitor logs” and pertains to “visitor activity both within the facility and within sensitive areas.”

9.5.1:

• Consolidated Applicability Notes into two bullets to clarify the types of devices to which the requirements at 9.5 do not apply.
• Moved the recommendation from the Applicability Note to Good Practice.

Requirement 10

10.4.1.1:

• Add information about establishing a baseline of normal audit activity under Good Practice. 
• Add a reference to the Information Supplement: Effective Daily Log Monitoring under further information. 

10.5.1

Update the heading from Good Practice to Purpose for better for better alignment with content.  

Requirement 11

11.2.1:

• PA-DSS has been discontinued back in 2021 and currently, PCI SSF is used. 
• Moved a note about unauthorized wireless technology use under Purpose.

11.3.1:

• Clarified that it applies to “critical or high-risk” vulnerabilities.
• Added Good Practice guidance on including multiple vulnerability sources in the management process.

11.3.1.1:

Applied to vulnerabilities not ranked as “high-risk” or “critical.”

11.3.1.3:

Same clarification as 11.3.1, applied to “critical or high-risk” vulnerabilities.

 11.3.2:

• Included guidance on incorporating external vulnerability scans into the management process.
• Referenced the PCI SSC ASV Program Guide under Further Information.

11.6.1:

• Applied to “security-impacting HTTP headers and the script contents of payment pages.”
• Updated frequency from “once every seven days” to “weekly.”
• Added notes on how the requirement applies to entity webpages and embedded payment forms.
• Expanded Purpose to detail detection capabilities.
• Provided guidance on evidence expectations from TPSP/payment processors.
• Clarified examples of detection mechanisms and stated the list is non-exhaustive.

Requirement 12

12.1.4

• Examples of common executive management titles from the Purpose section.
• Description of senior-level positions to the Good Practice section.
• Guidance on how to indicate information security knowledge for executive management roles in Good Practice.

12.3.1

• The requirement applies only to PCI DSS requirements that specify the completion of a targeted risk analysis.
• Analysis should justify the entity’s defined frequency or processes to minimize threat likelihood/impact.
• Further Information section referring to PCI SSC’s Targeted Risk Analysis guidance document and templates.

12.3.3

• Third bullet to “Documentation of a plan” to align with Requirement 12.3.4.
•  Applicability Note providing examples of PCI DSS requirements that require cryptography.

12.8.2

• The second bullet specifies that acknowledgments from TPSPs address the TPSPs’ responsibility.

• Applicability Notes to:

Clarify the difference between “agreement” and “acknowledgment.”

Confirm TPSP’s responsibility through written acknowledgment.

Separate examples of evidence showing TPSP compliance and add more examples.

12.9.1

• Clarify the difference between “agreement” and “acknowledgment.”
• Confirm TPSP’s responsibility through written acknowledgment.
• Emphasize that evidence of meeting a PCI DSS requirement is not the same as a written agreement.
• Include wording from PCI DSS v3.2.1 about TPSPs’ templates for appropriate acknowledgments.

12.9.2

• It applies to all TPSPs, removing specific service references.
• This requirement applies to TPSPs providing services that meet PCI DSS requirements or impact the security of customer account data.

Conclusion

The new PCI DSS v4.1 compliance framework encourages the integration of compliance and innovation, leading to enhanced security measures for our interconnected society. Partner with us as your compliance consultants to explore the groundbreaking advancements and implementation strategies presented by PCI DSS v4.1.

FAQs

The post What’s New in PCI DSS Version 4.1? appeared first on Kratikal Blogs.

*** This is a Security Bloggers Network syndicated blog from Kratikal Blogs authored by Shikha Dhingra. Read the original post at: https://kratikal.com/blog/whats-new-in-pci-dss-version-4-1/