If your business processes, stores, or transmits credit card and cardholder data, you should be on your way to enacting changes needed for your organization’s compliance with PCI DSS v4.0 which goes into effect on March 31, 2024.
Version 4.0 encompasses 13 new requirements in effect now for attesting compliance and 50 additional, future-dated requirements needed by March 31, 2025.
Of the 13 new requirements, Requirement 12.5.2 requires the performance of annual scoping exercises and may be challenging for merchants and service providers to meet and validate.
What is scoping?
In the context of PCI DSS, scoping involves identifying the systems, people, and processes in an organization that are involved in processing, storing, or transmitting cardholder data (CHD). Scoping plays a crucial role in PCI DSS compliance by helping to determine the boundaries of the cardholder data environment (CDE) so that an assessment is effective and comprehensive, in addition to identifying areas that require security controls. The CDE must be broad enough to include anything that has the potential to impact the security of cardholder data within the organization.
Thorough documentation is essential to the scoping process and should include management review and approval of any changes. Because scoping is intended to be an ongoing process, regular reviews and updates are needed to keep your scope accurate and up to date.
Defining and understanding Requirement 12
Scoping is an important step in PCI DSS compliance, helping organizations identify areas needing remediation and ensuring that cardholder data has appropriate protections.
PCI DSS v4.0 stipulates that Requirement 12.5.2 scoping be “…documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.” This requirement expands on a comprehensive approach that merchants and service providers must take regarding the annual scoping requirement.
Additional language in Section 3.1 of the PCI DSS v4.0 Report on Compliance specifies that merchants and service providers use an internal process separate from the validation of scope accuracy performed during a PCI DSS assessment by a PCI Qualified Security Assessor (QSA).
Know the flow of your cardholder data
For smaller merchants, annually documenting and confirming PCI DSS scope may be a relatively simple activity. For organizations with larger, more complex payment acceptance channels, proper scoping can be elusive, especially when cloud services are included.
Correctly identifying and documenting scope can be challenging if there are “blind areas” in the merchant’s internal perspective or a gap in resources regarding the seven scoping validation activities included in Requirement 12.5.2.
Answering these questions can help an organization better understand the flow of their cardholder data:
- What types of payment cards are accepted?
- Where is cardholder data collected, processed, stored, or transmitted?
- What systems or applications are involved in the cardholder data flow?
- What are the data elements that make up the cardholder data (i.e., PAN, expiration date, CVV)?
- Who has access to the cardholder data at each stage of the data flow?
- What measures are in place to protect the confidentiality and integrity of the cardholder data, such as encryption or access controls?
- Are there any third-party service providers or vendors involved in the cardholder data flow, and if so, what measures do they have in place to protect the data?
- What business processes or functions rely on cardholder data, such as payment processing or order fulfillment?
- How long is the cardholder data retained? What measures are in place to securely dispose of the data once it’s no longer needed?
What regulatory or industry requirements apply to storing or handling cardholder data, such as GDPR or HIPAA?
Inside a PCI assessment
Compliance with Requirement 12.5.2 is validated through a PCI assessment performed by a PCI QSA. The assessment includes documentation review and testing to confirm these areas:
- Review of meeting minutes supporting execution of 12.5.2 prior to an annual Attestation of Compliance (AOC) or Report on Compliance (ROC)
- Identification of all data flows for payment stages, including authorization, capture settlement, chargebacks, and refunds, and acceptance channels, including card-present, card-not-present, and ecommerce payments
- Updates to data-flow diagrams, per Requirement 1.2.4
- Identification of all locations where account data is stored, processed, and transmitted, including locations outside of the currently defined CDE, applications that process CHD, transmissions between systems and networks, and file backups
- Identification of all system components in the CDE, connected to the CDE, or that could impact security of the CDE
- Identification of all segmentation controls used and the environment(s) from which the CDE is segmented, including justification environments out of scope
- Identification of all connections from third-party entities with access to the CDE
- Confirmation that all identified data flows, account data, system components, segmentation controls, and connections from third parties able to access the CDE are included in scope
Base-level testing should examine the documented results of the scoping confirmation exercise performed and personnel interviews to verify that the reviews are performed for all elements specified in the requirement.
Scoping cloud services for PCI DSS compliance
Due diligence in managing third-party service providers is essential when cloud services are part of the CDE. This includes a solid understanding of how cloud services correlate to applicable PCI DSS requirements in order to correctly validate that the security controls in place, whether provided natively by the cloud security provider (CSP) or integrated with additional services, meet requirements for protecting cardholder data.
Due diligence in managing cloud services should include confirmation that:
- Industry standard data protection controls are in place
a. Strong cryptography and key management practices
b. Tokenization and masking of cardholder data when possible
c. Robust data loss prevention solutions
d. Data protection for all three states: data in transit, data in use, and data at rest - Authentication mechanisms, including multifactor authentication, are applied appropriately according to the access level to sensitive systems and data, if suitable
- Secure system management capabilities are provided and consistently followed, such as:
a. Patch management
b. Verification of code updates
c. Configuration management - Service providers employ strong, secure software life cycle development processes that map to industry standard frameworks and that their software supply chains do not introduce any weak links into the overall security infrastructure
Most CSPs maintain their own PCI compliance but ultimate responsibility for payment data security rests with the merchant account entity that allows acceptance of credit cards for payment, regardless of how specific responsibilities may be defined and allocated between an entity and a CSP.
Significant change should trigger scoping
The requirement clearly and concisely states the timing of when scope documentation and confirmation must occur, specifying “every 12 months” and understood to be at least once every 365 days (366 with leap years) or on the same date every year. It gets vaguer around scoping needed when “significant changes to the in-scope environment” occur. What’s seen as significant?
In PCI version 4.0, the Council provides more guidance for this, highlighting activity with the potential to impact the security of the CDE.
Any of the following are considered significant change in the context of PCI DSS requirements:
- 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
- Change of vendors/service providers or to their services that support the CDE or meet PCI DSS requirements on behalf of the organization
Change control and PCI compliance
A consistent, well-defined change control process can make it easier to identify which changes warrant review to determine the security impact on the CDE. Use a defined, “flag for review” step in the change control process when system or process changes meet the activities above.
Reference PCI requirement 6.4.2 for helpful guidance on the efforts needed to be performed when significant changes occur: “Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.”
Significant changes could require the following for PCI DSS compliance:
- Updating network and data-flow diagrams to reflect changes
- Configuring systems per standards, changing all default passwords, and disabling unnecessary services
- Protecting systems with required controls, such as file integrity monitoring (FIM), anti-malware, patches, and audit logging
- Ensuring that sensitive authentication data is not stored and that all account data storage is documented and incorporated into data retention policy and procedures
- Including new systems in quarterly vulnerability scanning
- Scanning systems for internal and external vulnerabilities, per Requirements 11.3.1.3 and 11.3.2.1.
Daunting, but do-able
The new 13 and future 50 requirements of PCI DSS v4.0 mark a major overhaul of PCI DSS requirements and may seem daunting, regardless of the size of your organization or team. Breaking down each requirement into stages can help your team prioritize the necessary steps. The timeline available here can help you understand flow and calculate your resources.
An ideal first step is to use a gap analysis to identify the current state of your PCI controls and the necessary actions needed for compliance. Our governance, risk, and compliance consulting team has working knowledge and experience in assisting organizations with PCI DSS compliance and provides PCI QSA services through Accudata Systems, a Converge Company. Reach out today to get started so you’re ready for the March 31, 2024, deadline.
Related Topics You Might Be Interested In
PCI DSS v4.0 Is Coming: Here’s What You Need to Know Now
PCI Compliance: SAQ A Changes With Big Impact for eCommerce Sites
