PCI DSS version 4.0 changed how risk is assessed. It retired the single annual organization-wide risk assessment and replaced it with the targeted risk analysis in Requirement 12.3.1: a focused analysis that justifies how often an entity performs certain flexible activities, such as the frequency of a control. A separate targeted risk analysis under Requirement 12.3.2 supports any control met through the customized approach. Each analysis identifies the assets protected, the threats, and the factors that drive how often the activity must occur.
Older versions of PCI DSS asked for one broad risk assessment a year. Version 4.0 took a different path: instead of a single document, it asks for focused, targeted risk analyses tied to specific decisions, mainly how frequently a flexible control needs to be performed. The shift makes risk analysis more concrete and harder to treat as a formality. This guide covers what changed, what a targeted risk analysis must cover, and how to document it.
What changed in v4.0
PCI DSS v4.0 removed the annual organization-wide risk assessment that earlier versions required under the old Requirement 12.2. In its place, Requirement 12.3.1 requires a targeted risk analysis for each PCI DSS requirement that the standard lets the entity perform at a frequency it defines. The targeted risk analysis is what justifies that frequency. Requirement 12.3.2 requires a separate targeted risk analysis to support each control implemented through the customized approach.
What a targeted risk analysis must cover
For the flexible-frequency case under 12.3.1, the analysis documents the asset being protected, the threat or threats the activity guards against, the factors that contribute to the likelihood or impact of the threat, and the resulting frequency at which the activity is performed, with a review of that frequency on a defined cadence.
| Element | What it captures |
|---|---|
| Asset | The asset or process the activity protects. |
| Threat | The threat the activity is meant to address. |
| Likelihood and impact factors | The factors that drive how likely the threat is and how serious the impact would be. |
| Frequency | The frequency the analysis justifies, and when it will be reviewed. |
How to document one
Step 1: Identify the activity and the asset
Name the flexible activity and the asset or process it protects.
Step 2: Identify the threats
Set out the threats the activity guards against.
Step 3: Weigh likelihood and impact
Document the factors that drive the likelihood and impact of those threats for your environment.
Step 4: Set and justify the frequency
State the frequency the analysis supports and the reasoning, then set a review cadence.
Step 5: Review on schedule
Revisit the analysis at least once every twelve months and when the environment changes.
Where it goes wrong
- Reusing the old single assessment. One organization-wide document is submitted where v4.0 expects per-activity targeted analyses.
- No frequency justification. The analysis names a threat but never connects it to the frequency it is supposed to justify.
- Never reviewed. The analysis is written once and not revisited as the environment changes.
PCI DSS risk analysis is now focused and tied to specific decisions. For the wider standard, see the PCI DSS compliance guide and the PCI DSS glossary; for a cybersecurity risk assessment in a regulated setting, see the NYDFS risk assessment guide.
Primary sources
- PCI DSS v4.0.1, Requirement 12.3.1: The targeted risk analysis requirement (the successor to the periodic risk assessment in Requirement 12.2).