PCI DSS 4.0: Identify Requirement Gaps and Automate Compliance

Requirements across security frameworks must evolve to account for new technology and safeguard against the latest threats. Serving as a baseline of technical and operational requirements designed to protect payment account data, the Payment Card Industry Data Security Standard (PCI DSS) is no exception since its initial release by the Payment Card Industry Security Standards Council (PCI SSC) in 2004. The core goal of PCI DSS is to protect cardholder data, supported by:

• Building and maintaining a secure network and systems 
• Maintaining a vulnerability management program
• Implementing strong access control measures
• Regularly monitoring and testing networks
• Maintaining an information security policy

While this set of security standards is not enforced by a specific law, PCI DSS compliance is a contractual agreement made between merchants, service providers, card brands, and the banks that process payments. Merchants and service providers are required to implement, assess, and attest compliance across 12 core security requirements—each including a subset of more specific requirements. Banks and other payment processors are then responsible for verifying compliance, managing potential risks, and imposing fines.

The PCI SSC published v4.0 in March 2022 and has since released minor revisions in v4.0.1. From identifying compliance gaps, scoping risk assessments, to implementing a Customized Approach, LogicGate is your partner in PCI compliance. 

What’s the Difference Between PCI DSS v4.0 and v3.2.1?

If you’re already PCI DSS v3.2.1 compliant, you may be wondering how much effort it will take to become fully compliant with v4.0. The good news is, we’re about to tell you! Risk Cloud’s automated control gap analysis helps teams compare two different versions of the same framework to identify coverage gaps and prioritize corrective action.

When comparing requirements published by the Payment Card Industry Security Standards Council, we find that 13.9% of PCI DSS 4.0 requirements do not have a similar, existing control already implemented as part of version 3.2.1. This analysis is supported by control relationships defined by the Secure Controls Framework (SCF). Below you will find a summary of the most notable gaps to address:

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

• 7.2.3: Ensure authorized personnel are approving required privileges.
• 7.2.4: Specifications for reviewing all user accounts, including third parties, and access privileges, including cadence.
• 7.2.5.1: Specifications for reviewing access by application and system accounts, including references to the appropriate targeted risk analysis.

Requirement 8: Identify Users and Authenticate Access to System Components

• 8.3.6: Additional password requirements in relation to requirement 8.3.1.
• 8.4.1: MFA requirements for all non-console access into the stored cardholder data environment for personnel with administrative access.
• 8.6.2: Additional password requirements for any application and system accounts that can be used for interactive login.

Requirement 9: Restrict Physical Access to Stored Cardholder Data

• 9.2.4: Consoles in sensitive areas are locked when not in use. 
• 9.5.1.2.1: Point of interaction (POI) device inspection details must be defined in the entity’s targeted risk analysis.

Requirement 12: Support Information Security with Organizational Policies and Programs

• 12.3.4: Specifications, including cadence, for reviewing hardware and software technologies in use. 
• 12.5.1: An inventory of system components that are in scope for PCI DSS, including a description of function/use, must be maintained and kept current.
• 12.6.2: Requirements for reviewing and revising the security awareness program.
• 12.8.4: Monitoring Third Party Service Providers’ PCI DSS compliance status at least once every 12 months.

How PCI DSS v4.0 Compares to Other Common Frameworks

If you’re new to PCI DSS altogether, don’t worry! We’ve got you covered. Let’s use Risk Cloud’s automated control gap analysis to compare PCI DSS v4.0 to popular frameworks that your organization may already be compliant with so you can reduce redundant controls, effectively identify remaining gaps, and accelerate compliance.

PCI DSS v4.0 Coverage Based on SOC 2 Compliance

SOC 2 is a voluntary framework designed to protect stored customer data through the core pillars of security, availability, processing integrity, confidentiality, and privacy. Many companies require vendors to demonstrate SOC 2 compliance as part of their core buying requirements. If you’re already SOC 2 compliant, your broader focus on data security and privacy will help minimize the investment needed to become PCI DSS compliant. Due to the niche focus of PCI DSS on protecting cardholder data and securing merchant technology, control gaps include but are not limited to:

Requirement 3: Protect Stored Account Data

• Focus primarily on customer data retention practices, like card verification codes and pins, and the protection of primary account numbers. Specifications surrounding critical security control systems and failure response are also included.

Requirement 8: Identify Users and Authenticate Access to System Components

• Controls to evaluate within this section center around password, MFA implementation, and invalid authentication requirements.

Requirement 12: Support Information Security with Organizational Policies and Programs

• The primary gaps within this section include security awareness training, incident response, and technology review requirements.

PCI DSS v4.0 Coverage Based on NIST CSF Compliance

The NIST Cybersecurity Framework (NIST CSF) is a commonly adopted framework for managing cybersecurity risk. While NIST CSF and PCI DSS share the goal of enhancing data security, the specificity of payment systems and stored cardholder data within PCI DSS requirements leaves a 25.4% coverage gap when compared to NIST CSF outcomes.

If you’ve already implemented NIST CSF and would also like to become PCI DSS compliant, the most notable areas of attention will likely be:

Requirement 3: Protect Stored Account Data

• Similar to the SOC 2 comparison, there are gaps in relation to customer data retention practices, the protection of primary account numbers, and specifications surrounding critical security control systems.
• Additionally, NIST CSF does not directly cover requirements surrounding the protection, storage, access, and change management of cryptographic keys.

Requirement 8: Identify Users and Authenticate Access to System Components

• Similar to the SOC 2 comparison, there are gaps in relation to password, MFA implementation, and invalid authentication requirements. NIST CSF does not directly cover more specific requirements like password change management and misuse.

Requirement 9: Restrict Physical Access to Cardholder Data

• This gap area focuses primarily on visitor badge and log management and Point of Interaction (POI) device inspections.

Requirement 11: Test Security of Systems and Networks Regularly

• This section’s core gaps include requirements for internal and external penetration testing and finding remediation.

PCI DSS v4.0 Coverage Based on ISO 27001 Compliance

If you’re exploring PCI DSS Compliance from the lens of existing ISO 27001 control coverage, unfortunately, there’s quite a bit of work left to be done. Here we see that only 25.7% of PCI DSS requirements map to a related ISO 27001 control, leaving a substantial gap of 74.3%.

Requirement 1: Install and Maintain Network Security Controls

• Here, you’ll take steps to protect the Cardholder Data Environment (CDE) through network and data-flow documentation, inbound and outbound traffic restrictions, and ensuring no direct access from untrusted networks. Requirements also include configuration standards and review specifications for Network Security Controls (NSC)

Requirement 2: Apply Secure Configurations to All System Components

• This section of PCI DSS compliance focuses heavily on configuration standards to ensure the security of new systems and wireless environments connected to the CDE, the remediation of known vulnerabilities, and ongoing alignment to industry best practices. Additional requirements include how to manage primary functions requiring different security levels and vendor default accounts.

Requirement 3: Protect Stored Account Data

• Coverage gaps within this section of PCI DSS compliance when compared to existing ISO 27001 controls are similar to those reported in the NIST CSF analysis above.

Requirement 5: Protect All Systems and Networks from Malicious Software

• Specific system components are in scope for the required deployment of anti-malware solution(s). Your anti-malware solutions(s) must be kept up-to-date and perform periodic and real-time scans or perform continuous behavioral analysis. Audit logs for all anti-malware solution(s) are enabled and retained with permissions to disable or alter mechanisms being restricted appropriately. For those systems not in scope, specific evaluation criteria is required. Additionally, measures must be taken to protect personnel against phishing attacks.

Requirement 6: Develop and Maintain Secure Systems and Software

• Any control gaps within this section will center around the secure development and maintenance of bespoke and custom software, including developer training, coding best practices, and code reviews. Your vulnerability management program must also meet certain standards as outlined within this section’s requirements.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

• An access control model is defined and appropriately minimizes access, like granting the least privileges required to perform a job function. Specifications surrounding specific privileges, like the ability to query repositories of stored cardholder data, are also detailed. Access reviews must be performed for all user accounts, including third parties, every six months.

Requirement 9: Restrict Physical Access to Cardholder Data

• PCI DSS will require you to monitor sensitive areas within the physical CDE and implement controls that restrict physical access to publicly accessible network jacks, consoles, wireless access points, gateways, networking/communications hardware, and telecommunication lines with clear personnel identification procedures that ensure proper individual authorization. The management of any media holding sensitive cardholder data will also be a critical gap to address, including backups, inventory logs, and destruction requirements.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

• To comply with PCI DSS, it is critical to maintain the appropriate audit logs. Key focus areas include logging all individual user access and actions to stored cardholder data, changes to identification and authentication credentials, and the creation and deletion of system-level objects. Audit logs must be protected from modification, include change-detection mechanisms, and be reviewed at a set cadence. Time synchronization requirements are also critical to ensure the integrity of logged event details.

Requirement 11: Test Security of Systems and Networks Regularly

• In addition to the Requirement 11 gaps noted in the NIST CSF analysis above, you will need to implement controls surrounding authorized and unauthorized wireless access point management, internal and external vulnerability scanning, intrusion-detection and -prevention techniques—like monitoring all traffic at the perimeter of the CDE and having a clear suspected compromise protocol—and change-detection mechanisms that monitor critical files and HTTP headers.

Streamlining Targeted Risk Analysis Scoping

A key aspect of accelerating audit readiness is appropriately scoping PCI DSS risk assessments. Enterprise-grade organizations often spend months mapping out impacted business units and all related processes, assets, and risks before starting the assessment process. A manual approach to this scoping phase not only delays audit-readiness, but can easily lead to too many or too few assessments being launched. LogicGate customers have streamlined this process with Risk Cloud’s assessment scoping tool.

Let’s say you’re a multinational hospitality company with hundreds or thousands of properties. Risk Cloud can strategically limit the scope of your assessments to specific assets impacted by PCI DSS requirements in just a few clicks. Program leaders can simply select a facility and its systems to automatically select related controls. Once the in-scope items are confirmed, Risk Cloud automatically generates each individual assessment and assigns them to the appropriate control owners.

Meeting PCI DSS Compliance with the Customized Approach

If your organization has a complex or unique compliance environment that cannot easily align with standard PCI DSS requirements, the Payment Card Industry Security Standards Council offers the option to instead demonstrate how your internal control set meets each required security objective as part of PCI DSS v4.0. Before working with a PCI Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) to evaluate each custom control for adequacy and effectiveness, there are a few common challenges to you may need to address:

• Standardizing control documentation: Your organization will be required to describe each custom control in detail, including design, implementation, and operational processes. It is critical to standardize how and where this information is gathered. Leveraging a centralized platform like Risk Cloud can help you map custom controls to specific regulatory requirements, identify coverage gaps, automate task management, and standardize documentation. 
• Collecting evidence: Ensure the latest control evidence is accessible for evaluation by automating the collection process. Risk Cloud aggregates data from 100+ common evidence sources so you can avoid admin-heavy coordination with control owners and efficiently demonstrate your controls’ effectiveness.
• Connecting requirements to active policies, assets, and risks: A key aspect of PCI DSS compliance is understanding what policies, procedures, assets, risks, and controls are related to each requirement. Risk Cloud leverages the power of AI to intelligently recommend data connections from across your GRC environment to remove information silos, ensure data integrity, and save you time.

Automating your PCI DSS Compliance Program and Beyond

You’re likely well on your way to achieving PCI DSS compliance — if you haven’t already. If during that process you’ve spent time on manual workarounds and don’t have clear visibility into your compliance posture, let us know. Our team would be happy to show you how your peers are leveraging Risk Cloud to help automate their compliance programs, including PCI DSS.

Request a custom GRC software demo from one of our experts