Countdown to Compliance: Validating Scope Under PCI DSS v4.0

The Payment Card Industry Data Security Standard version 4.0 (PCI DSS v4.0) represents a significant upgrade to the previous version (v3.2.1). One of the substantial changes relates to how organizations must validate the scope of their environment for purposes of PCI DSS compliance assessments.

Tevora has been a certified PCI DSS QSAC (Qualified Security Assessor Company) since the standard was created in 2004 and has a deep understanding of PCI DSS v4.0 and its requirements for scope validation. In this blog post, we’ll review the key requirements for validating PCI DSS v4.0 scope in your environment and the steps you should take to prepare your organization for a successful compliance assessment.

PCI DSS v4.0 Implementation Timeline

The planned timeline for implementation of PCI DSS v4.0 is summarized below. PCI DSS v3.2.1 will remain active for two years after v4.0’s publication. Some v4.0 requirements are future-dated and do not become effective until March 31, 2025. This provides organizations time to become familiar with the new version and plan for and implement the needed changes.

PCI DSS v4.0 Implementation Timeline[1]

To understand PCI DSS v4.0 scoping validation requirements, it’s important to understand the following key terms:

Key PCI DSS v4.0 Terms

Term	Definition
Cardholder Data Environment (CDE)	The CDE is comprised of: •   The system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data and/or •   System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD.
Account Data	Account data consists of cardholder data (CHD) and/or sensitive authentication data (SAD).
Cardholder Data (CHD)	At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.
Sensitive Authentication Data (SAD)	Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card validation verification codes/values, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.
Bespoke and Custom Software	•   Bespoke software is developed for the entity by a third party on the entity’s behalf and per the entity’s specifications. •   Custom software is developed by the entity for its own use.
System Component	Any network devices, servers, computing devices, virtual components, or software (including bespoke and custom software) included in or connected to the CDE, or that could impact the security of the CDE.
Media	Physical material, including but not limited to, electronic storage devices, removable electronic media, and paper reports.

How Should We Determine the Scope of Our PCI DSS v4.0 Assessment?

The first step in preparing for a PCI DSS v4.0 assessment is to accurately determine the scope of your environment that will be reviewed in the assessment.

According to PCI DSS v4.0 Requirement 12.5.2, you must confirm this scope by identifying all locations and flows of account data, and identifying all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers, remote access servers, logging servers) to ensure they are included in the PCI DSS scope.

All types of systems and locations should be considered during the scoping process, including backup/recovery sites and fail-over systems.

The primary methods for determining your scope are documentation reviews and testing.

To successfully perform an accurate scoping, you must cover to people, processes, and systems that could impact the security of the CDE (or that connect directly or indirectly to the CDE).

As you perform this scope confirmation, we recommend that you ensure all locations are secure and that CHD is not stored unless absolutely necessary.

How Often Do We Need to Confirm Our PCI DSS v4.0 Scope?

PCI DSS v4.0 requires that you perform a documented scoping exercise annually, and after any significant changes to the in-scope environment (e.g., people, systems, or processes). Third-party service providers are required to perform scope validation bi-annually, and after any significant changes to the in-scope environment. (Requirement 12.5.2).

Significant Changes Triggering Additional Scope Validation

Any of the following are considered a significant change in the context of PCI DSS requirements and will consequently require a scope validation:

• New hardware, software, or networking equipment added to the CDE.
• Replacement or major upgrade of any hardware or software in the CDE.
• Change to the flow or storage of account data.
• Change to the boundary of the CDE and/or the scope of the PCI DSS assessment.
• Change to the underlying, supporting infrastructure of the CDE, including changes to directory services, time servers, logging, and monitoring.
• Changes to organizational structure that may impact PCI DSS scope and applicability of controls.
• Change of vendors/service providers or to their services that support the CDE or meet PCI DSS requirements on behalf of the organization.

What Are Key Things We Should Consider When Scoping Our Environment?

Here are key things to consider when scoping your environment under PCI DSS v4.0:

Key PCI DSS v4.0 Scoping Considerations

Category	Considerations
Account Dataflows	Identification of how cardholder data (CHD) and sensitive authentication data (SAD) are stored, processed, and/or transmitted by your organization’s people, processes, and technologies.
Account Data Storage	•   Identification of all databases, tables, files and/or folders storing CHD and/or SAD. •   Identification of the Account Data elements (e.g., PAN, CVV, PIN) stored and the method for transforming each element to prevent readability at-rest (e.g., tokenization, hashing, encryption, masking, truncation).
In-Scope Networks	•   Identification of all networks and subnets that store, process, and/or transmit Account Data, constituting the CDE. •   Identification of all networks that do not store, process, and/or transmit Account Data, but are in-scope due to connectivity or security impact to the CDE. •   Identification of network security controls implemented for the purposes of logically segmenting the CDE for the purposes of PCI DSS assessment scope reduction.
In-Scope System Components	•   Identification of all system components that store, process, or transmit CHD/SAD, constituting the CDE. •   Identification of system components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components •   Identification of system components that could impact the security of the CDE.
In-Scope Third-party Service Providers (TPSP)	Identification of third-party services that influence the security of the CDE, including: •   TPSPs that are used to store, process, or transmit Account Data •   TPSPs that have access to the CDE •   TPSPs that manage in-scope system components •   TPSPs that impact the security of the CDE
In-Scope Locations/Facilities	Identification of locations/facilities with physical access to CDE components or areas that could affect the security of the CDE, such as data centers or server rooms. This should include identification of the three different types of areas treated differently under PCI DSS: •   “Sensitive Areas” which refers to the subset of the CDE and is any area that houses systems considered critical to the CDE, such as datacenters and server rooms. •   “CDE” which refers to all locations and facilities that contain CDE systems and processes. •   “In-scope Facilities” which refers to types of controls to be applied more broadly at the physical boundary of a business premise within which CDEs and Sensitive Areas reside.
In-Scope People and Business Functions	•   Identification of all people and business processes that store, process, or transmit CHD/SAD, constituting the CDE. •   Identification of people and business processes that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components. •   Identification of people and business processes that could impact the security of the CDE.
In-Scope Media	Identification of physical material, including but not limited to, electronic storage devices, removable electronic media, and paper reports/hard-copy materials storing Account Data.
In-Scope Shared Accounts and System/Application Accounts	•   Identification of group, shared, or generic accounts, or other shared authentication credentials (e.g., break-glass accounts). •   Identification of all accounts used by systems or applications. •   Identification of all accounts used by systems or applications that can be used for interactive logon.

What Documentation is Required?

PCI DSS v4.0 requires comprehensive documentation for the in-scope elements of your environment. This section outlines documentation requirements and provides requirement numbers for each.

Account Dataflows

• [Req 1.2.4] Data-flow diagram(s) showing all account data (both cardholder data and sensitive authentication data) flows across facilities, networks, systems, people, and business processes.
• [Req 4.2.1.1] Inventory of trusted keys and certificates used to safeguard PAN during transmission.
• [Req 12.3.3] Up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.

Account Data Storage

• [Req 3.2.1] Data retention and disposal policies, procedures, and/or processes that include:
  • Specific retention requirements for stored account data defining length of retention period with documented business justification.
  • Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
  • A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

• [Req 3.3.1] Documented business justification for storage of sensitive authentication data (Track, CVV, and PIN/PIN Block data) and documented procedures for deletion.
• [Req 3.6.2] Documented cryptographic architecture, which should include
  • Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.
  • Preventing the use of the same cryptographic keys in production and test environments.
  • Description of the key usage for each key.
  • Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4.
• [Req 3.7.8] Key Custodian signed acknowledgement of responsibilities.
• [Req 3.7.9] Customer guidance for key management (if application/service/process involves sharing cryptographic keys with clients for transmission or storage of account data).

In-Scope Networks

• [Req 1.2.3] Network diagram(s) showing:
  • All connections between the CDE and other networks, including any wireless networks, Illustrates all network security controls that are defined for connection points between trusted and untrusted networks.
  • Illustrates how system components storing cardholder data are not directly accessible from the untrusted networks.
  • Includes the techniques (such as intrusion-detection systems and/or intrusion-prevention systems) that are in place to monitor all traffic:
  • The perimeter of the cardholder data environment.
  • Critical points in the cardholder data environment.
• [Req 1.2.5] List/documentation of all open services, protocols, and ports, with business justification for each.
• [Req 1.2.7] Results of twice annual firewall/network security control ruleset reviews.
• [Req 12.4.5] Results of twice annual segmentation testing (if segmentation is used to reduce the scope of the assessment).
• [Req 12.5.2] List of all Network Segments/IP Ranges/CIDR Blocks and identification of the purpose for each.

In-Scope System Components

• [Req 12.5.1] Inventory of all in-scope system components, with classifications using the following criteria:
  • “CDE System Components” that store, process, or transmit CHD/SAD.
  • “Connected-to System Components” that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components.
  • “Security Impacting System Components” that could impact the security of the CDE.

See Section “4 Scope of PCI DSS Requirements” (Pages 9-10) in the PCI DSS v4.0 March 2022 publication for full details on System Component types that should be considered.

• [Req 9.5.1.1] List of POS/POI devices containing make/model/location/identifier.
• [Req 11.2.2] Inventory of authorized wireless access points, including a business justification for each.
• [Req 12.3.4] Documented results from annual review of hardware & software technologies in use for purposes of proactive planning for “end of life”.
• [Req A1] Identification of applications, services, and/or platforms that would be deemed in-scope for Appendix A for “Multi-Tenant Service Providers”. This would generally include services that involve:
  • Infrastructure Hosting – Service providers host system components on behalf of customers/clients.
  • Data Hosting – Service providers stores PCI account data on behalf of customers/clients and customers/clients can manage or view this account data through system user/application interfaces. (this includes Applications made for B2B Customers that allow input and viewing of card data).

In-Scope Third-party Service Providers (TPSP)

• [Req 12.8.1] List of all TPSPs with which account data is shared or could impact the security of account data.
• [Req 12.8.4] Service provider AOCs and relevant evidence of program to monitor PCI DSS compliance of service providers annually.
• [Req 12.8.5] Information maintained about which PCI DSS requirements are managed by each TPSP, and which are managed by your organization, and any that are shared between the TSPS and your organization (e.g., responsibility matrices).

In-Scope Locations/Facilities

• [Req 9, 12.5.2] List of locations and facilities in-scope, with appropriate classification using the following three categories:
  • Sensitive Areas” which refers to the subset of the CDE and is any area that houses systems considered critical to the CDE, such as data centers and server rooms.
  • “CDE” which refer to all locations and facilities that contain CDE systems and processes.
  • “In-scope Facilities” which refer to types of controls to be applied more broadly at the physical boundary of a business premise within which CDEs and Sensitive Areas reside.

In-Scope People and Business Functions

• [Req 7.3.1, 7.3.2] List of users/roles/teams who have:
  • Ability to view or access Account Data or to access systems with Account Data.
  • Administrative access to in-scope system components.
  • Access to process one card number at a time to facilitate singular transactions.
• [Req 8.2.7] List of third-party service provider user accounts used to remotely access, support, or maintain in-scope system components.

In-Scope Media

• [Req 1.2.4] Account data flows, including those related to processes that involve Account Data stored, process, and/or transmitted using media.
• [Req 9.4.5.1] Media inventory logs.

In-Scope Shared Accounts and System/Application Accounts

• [Req 8.2.2] Documented business justification for group, shared, or generic accounts, or other shared authentication credentials (e.g., break-glass accounts).
• [Req 8.6.1] Inventory of system/applications accounts running on in-scope system components, including documented business justification for accounts that can be used for interactive logon.

Additional Resources

Below are additional resources that provide a deeper dive into the topics covered in this blog post:

• PCI DSS v4.0 At a Glance
• PCI DSS Summary of Changes from v3.2.1 to v4.0 – December 2022
• PCI DSS Requirements and Testing Procedures, Version 4.0, March 2022
• Tevora Webinar: Deciphering PCI DSS v4.0: How to Prepare your Organization
• Tevora Blog Post: PCI DSS Launches Version 4.0

We Can Help

As an experienced Payment Card Industry Qualified Assessor, Tevora’s team of experts can answer any questions you have about PCI DSS v4.0, including questions about scoping validation. We would also welcome the opportunity to help your organization plan for and conduct PCI DSS v4.0 scoping validation. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

---

[1] PCI DSS 4.0 At a Glance, v4.0, December 2022