How to Conduct a Risk-Based Assessment Aligned with PCI DSS 4.0 Compliance

PCI DSS 4.0 introduces a different way of thinking about security and compliance. Instead of following a fixed list of controls across the board, organizations are now expected to look closely at their environments and identify what needs the most attention.

This version of the standard leans heavily into risk awareness. Businesses are expected to understand their vulnerabilities and design their security efforts around them.

The focus is on relevance. Each control should fit the context it's applied to. The assessment process becomes more strategic, tailored, and connected to real-world threats.

Follow the steps below which is a risk-based assessment outline aligned with PCI DSS 4.0 compliance expectations.

1. Understand the Scope

Define the boundaries of the Cardholder Data Environment (CDE). The CDE includes all systems that store, process, or transmit cardholder data, such as POS terminals, web applications that collect payment details, databases that retain card information, and payment interfaces that send bank transactions. Even systems that only temporarily interact with cardholder data fall within scope.

Supporting services like authentication servers, DNS, DHCP, patch management tools, and logging infrastructure may not directly handle sensitive data, but can still impact CDE security. If compromised, these systems could give attackers access to the data.

Network segmentation can reduce the number of systems in the PCI DSS scope, but firewall rules alone are insufficient. Controls must be recorded, boundaries must be maintained, and testing should happen often to verify that systems outside the CDE remain isolated.

It's also advised that organizations revisit the defined scope each year and after events like shifting to cloud infrastructure, introducing new payment tech, changing how card data moves, or undergoing a merger.

2. Identify Threats and Vulnerabilities

PCI DSS 4.0 expects organizations to identify and document threats relevant to their specific environment. The focus is on real, observable risks tied to the business's operations and systems.

These might include malware or ransomware targeting payment applications, insider threats from privileged users, vulnerabilities introduced by third-party vendors, and security gaps from misconfigured or outdated systems.

A complete risk picture requires input from multiple sources. Internal incident records can reveal patterns of recurring issues. Scanning tools will help technical flaws that may already exist in the environment.

From reliable sources, external threat feeds can help assess the methods attackers are actively using. Reports detailing breaches in similar industries can offer a useful perspective on real-world exposure.

All of this input, when pulled together, ought to create a written risk log that connects identified threats with the corresponding security measures in place.

3. Evaluate Impact and Likelihood

Once risks are identified, each one should be evaluated based on two factors: impact and likelihood. Impact refers to potential consequences if a risk materializes — such as financial loss, data exposure, system downtime, or regulatory penalties. Likelihood considers how probable the event is, based on existing controls and current threat activity.

A simple high/medium/low scale is usually sufficient, as long as it is applied consistently and supported by clear documentation. Relevant input could include past security incidents, how well existing controls have performed, and current external threat data.

Such an in-depth evaluation makes it easier to decide which risks need to be addressed right away and which ones can be observed and managed over a longer period.

4. Determine Control Requirements

Each identified risk should map to one or more PCI DSS controls intended to reduce or eliminate it. Version 4.0 provides flexibility in how requirements are met, offering two options for many controls: the defined approach and the customized approach.

The defined approach involves implementing the control exactly as specified. For example, suppose the requirement calls for multi-factor authentication for administrative access. In that case, the defined approach means applying MFA without modification using the specific methods and conditions outlined in the standard.

The customized approach allows alternative controls if they meet the intent of the original requirement. This path requires documented risk analysis, a strong justification, and proof that the alternative provides the same or greater level of protection.

Organizations should only use the customized approach when clear evidence is available that existing controls already meet or exceed the security goal. For example, suppose the standard calls for a specific authentication method, but a different method already in use provides equal or better protection.

In that case, that approach can be documented as a valid alternative, supported by thorough analysis and validation.

5. Document Everything

Thorough documentation helps with compliance when working within a risk-based model. Every assumption, decision, and outcome must be recorded. This starts with the risk assessment methodology, which should explain how threats are identified, impact and likelihood are measured, and how mitigation priorities are set.

Organizations should document each identified risk, its potential severity, and the reasoning behind the selected control when a customized approach is used. This includes why the defined approach wasn't suitable and how the alternative better fits the environment.

Supporting evidence such as test results, audit logs, and system records should be maintained to demonstrate that controls function as intended. Although this documentation is mainly for internal use, it is critical during the compliance review.

Qualified Security Assessors (QSAs) rely on this documentation for decision making and validation that security objectives are being met.

6. Review and Update Regularly

Risk assessments must be updated whenever changes occur that could affect how cardholder data is processed or protected. These changes relate to system upgrades, network configuration, onboarding new vendors or services, and data flow modifications.

After the risk assessment, the security team can identify new threats or determine whether current controls remain effective. Security incidents, whether successful attacks or near misses, also warrant a review.

In addition to updates triggered by specific events, organizations conduct a structured risk review at least annually, following PCI DSS 4.0 expectations. The review must cover recent threat data, changes to system design, previous incidents, and results from internal or external audits.

Any adjustments or findings from this process should be recorded, including who handled the review, what areas were examined, and what actions were taken. Maintaining versioned records allows organizations to demonstrate how risk has been managed over time, providing transparency and accountability during assessments.

Get the PCI DSS 4.0 Checklist

To support a practical, risk-based approach to PCI DSS 4.0 compliance, Fortanix has developed a detailed checklist that maps key requirements to real-world data security controls.

This resource outlines how Fortanix solutions, including Data Security Manager (DSM) and Confidential Computing Manager (CCM), help organizations protect stored cardholder data, secure cryptographic keys, control access, and maintain continuous visibility across hybrid and multicloud environments.

The checklist explains how Fortanix solutions help organizations meet the PCI DSS 4.0 requirements for encryption, key management, secure development practices, and ongoing monitoring.