Introduction

PCI DSS v4.0 and the Risk Assessment Upgrade It Requires

PCI DSS v4.0 introduced significant changes to risk assessment requirements that many e-commerce organisations have not yet fully operationalised. The standard's move from a prescriptive compliance model to a more outcomes-based framework places greater emphasis on the organisation's own risk assessment capability — its ability to identify, assess, and treat risks specific to its cardholder data environment rather than simply implementing a defined control set.

Requirement 12.3 of PCI DSS v4.0 specifically mandates a targeted risk analysis for each requirement where the standard offers a customised implementation approach, and for requirements where the organisation needs to determine the frequency of activities. This represents a qualitative shift from v3.2.1: organisations can no longer simply implement the prescribed controls. They must document a risk-based rationale for their implementation decisions — and that documentation must be produced through a structured risk assessment process.

The practical implication is significant. Organisations that treated PCI DSS compliance as a control implementation exercise under v3.2.1 now need to operate a genuine risk assessment capability. The targeted risk analyses required by v4.0 are not a documentation exercise that can be completed retrospectively. They are a governance process that must be maintained ongoing, updated when the cardholder data environment changes, and available to QSA review at assessment time.

What Has Actually Changed: v3.2.1 vs v4.0 Risk Assessment Requirements

Understanding the specific changes between versions is essential for e-commerce organisations assessing their compliance programme gaps. The changes are more significant than many organisations have recognised.

• Targeted Risk Analysis (12.3.1): v4.0 requires a formal targeted risk analysis for any requirement that the organisation implements through a customised approach. This is new — v3.2.1 did not require documented risk analysis for implementation decisions. Every customised control decision now requires a risk analysis artefact.
• Frequency Determination (12.3.2): Where v3.2.1 specified fixed frequencies for activities like log review, vulnerability scanning, and access reviews, v4.0 allows organisations to determine appropriate frequencies based on risk analysis — but requires documented risk analyses to justify those determinations. Organisations that have maintained v3.2.1-era fixed frequencies must now document whether those frequencies are risk-appropriate.
• Cloud Shared Responsibility Mapping: v4.0 explicitly requires that organisations using cloud services document the shared responsibility boundaries for PCI DSS requirements. Which controls are the cloud provider's responsibility, which are the organisation's, and where residual risk requires compensating treatment — this mapping is a v4.0 requirement that most organisations have not formally produced.
• Authenticated Scanning (11.3.1): v4.0 requires that internal vulnerability scans use authenticated scanning to increase detection accuracy. The risk assessment implications of shifting from unauthenticated to authenticated scanning — including the credential management requirements and the potential for greater system impact — require documentation.
• Targeted Penetration Testing (11.4.1): v4.0 introduces more specific requirements for penetration testing methodology, including segmentation validation testing. The risk assessment that supports scope definition for penetration testing must now be explicitly documented.

The Specific Risk Assessment Updates E-Commerce Organisations Need

E-commerce organisations that completed their last formal risk assessment under PCI DSS v3.2.1 requirements are carrying documentation gaps under v4.0. Addressing these gaps requires a structured update to both the risk register and the risk assessment processes that support it.

• Cardholder Data Environment (CDE) scope documentation: v4.0 places greater emphasis on accurate CDE scoping as the foundation of all compliance obligations. The risk assessment must document the current CDE scope, including all system components that store, process, or transmit cardholder data, and any systems that could affect the security of those components.
• Cloud provider shared responsibility documentation: For e-commerce organisations using cloud-hosted payment processing, the shared responsibility boundaries for each PCI DSS requirement must be explicitly mapped and documented. This is a v4.0 requirement that most organisations have not formally addressed.
• Targeted risk analyses for customised implementations: Every PCI DSS requirement implemented through a customised approach requires a documented targeted risk analysis. E-commerce organisations that have customised implementations — common in areas like authentication, logging, and network segmentation — must produce these analyses.
• Third-party risk assessment updates: v4.0 strengthens requirements around third-party service provider management, requiring documented evidence of each TPSP's compliance status and a formal process for ongoing monitoring. E-commerce organisations with multiple payment processing, fraud detection, and data analytics service providers need to update their third-party risk documentation.
• Risk register update for v4.0 scope: The risk register must be updated to reflect the v4.0 requirement set, including new risks introduced by authenticated scanning, expanded penetration testing scope, and strengthened authentication requirements.

Using Structured Risk Assessment to Support QSA Engagement

Qualified Security Assessors conducting PCI DSS v4.0 assessments will expect to review the targeted risk analyses that support customised implementation decisions. Organisations that arrive at a QSA assessment with structured, documented risk assessment outputs — covering all v4.0 requirements where discretionary implementation is claimed — complete assessments faster, with fewer findings, and with lower remediation costs than those that produce documentation reactively under assessment pressure.

The QSA assessment process is not a documentation audit. It is an evidence-based evaluation of whether the organisation's security controls actually protect cardholder data. But documentation that accurately reflects the control environment makes the QSA's job easier and reduces the likelihood of findings based on documentation gaps rather than genuine control deficiencies.

• Pre-assessment documentation review: Structured risk assessment outputs provide the documentation baseline that QSAs use to scope their testing. Complete documentation reduces the assessment time required to establish what controls exist and why.
• Customised approach evidence: For any requirement implemented through PCI DSS v4.0's customised approach, the targeted risk analysis is the primary evidence the QSA will review. The quality of that analysis directly affects the QSA's confidence in the customised control's effectiveness.
• Remediation efficiency: Risk assessment outputs that identify control gaps before the QSA engagement allow the organisation to remediate before assessment rather than after, reducing the cost of findings and the timeline pressure of post-assessment remediation.

How Codec Networks Helps: Building a PCI DSS v4.0 Risk Assessment Programme

Codec Networks’ Risk Assessment & Mitigation Strategy service provides e-commerce organisations with the structured risk assessment capability that PCI DSS v4.0 requires — producing the targeted risk analyses, shared responsibility documentation, and QSA-ready evidence packages that the standard’s outcomes-based approach demands.

Organisations transitioning from v3.2.1 compliance to v4.0 requirements, our service delivers:

• Targeted Risk Analysis Production: We produce the documented targeted risk analyses that v4.0 Requirement 12.3 mandates for every customised implementation decision — covering authentication frequency determinations, log review cadences, and access review schedules — with the methodology rigour that QSAs evaluate at assessment time.
• Cloud Shared Responsibility Mapping: For cloud-hosted cardholder data environments, Codec Networks explicitly maps PCI DSS control responsibilities between cloud provider and customer — identifying the residual customer obligations that shared responsibility arrangements do not automatically address and documenting the compensating controls in place.
• CDE Scope Documentation and Validation: We produce the accurate, current CDE scope documentation that v4.0 requires as the foundation of all compliance obligations — including all system components that store, process, or transmit cardholder data and systems that could affect their security.
• Third-Party Service Provider Assessment: v4.0’s strengthened TPSP requirements are addressed through systematic assessment of all payment processing, fraud detection, and data analytics providers — with documented compliance status evidence and ongoing monitoring process design.
• Pre-QSA Engagement Documentation Review: Codec Networks conducts a structured review of risk assessment documentation six to eight weeks before QSA assessment — identifying and closing documentation gaps before the assessment period begins and enabling organisations to arrive with a compliance position that reflects the security programme they have actually built.

Conclusion

The Customised Approach: Opportunity and Documentation Obligation

PCI DSS v4.0's customised approach represents a significant philosophical shift in how the standard treats security controls. Under the defined approach — which remains available and used by most organisations — the organisation implements the specific control the standard prescribes. Under the customised approach, the organisation implements a control of its own design that achieves the stated security objective, supported by a targeted risk analysis demonstrating that the custom control meets the objective.

PCI DSS v4.0 risk assessment requirements are more demanding than their predecessors — and more aligned with genuine risk management practice. E-commerce organisations that update their risk management programmes to meet v4.0 requirements are building capability that serves both compliance obligations and real governance needs simultaneously. The targeted risk analyses required by v4.0 are not compliance overhead — they are the documentation of the risk-based thinking that should underpin every material security decision in a cardholder data environment. Organisations that invest in producing them proactively will arrive at QSA assessments with a compliance position that reflects the security programme they have actually built.