Risk Assessment
PCIComplianceHubLast updated
Working out what needs protecting, what threatens it, and how likely and costly each threat would be, so that controls go where the exposure is greatest. PCI DSS v4.0.1 does not ask for one enterprise-wide exercise. It asks for targeted risk analyses: one for each requirement that lets the entity choose its own frequency or process (12.3.1), and one for each requirement met with the customised approach (12.3.2).
Applies to. Any entity assessed against v4.0.1, whenever a requirement says the frequency or method is set by the entity's targeted risk analysis. 5.2.3.1 is one case: how often systems judged not at risk from malware are re-evaluated comes from a targeted risk analysis done under 12.3.1. 12.3.1 also requires each analysis to be reviewed at least once every 12 months, and 12.3.2 requires senior management approval and a controls matrix for every requirement met through the customised approach.
Example. A retailer decides to check its list of malware-exempt systems every six months rather than every quarter. To justify that under 5.2.3.1 it writes a targeted risk analysis naming the systems, the malware threat, the factors that make infection more or less likely, and why six months keeps that risk low, then diarises the annual review 12.3.1 requires.
Limits. A risk assessment in the general security sense is not the same thing as the targeted risk analysis the standard asks for: a targeted risk analysis is narrow, covering one requirement, one threat and one justified frequency or process. It cannot be used to skip a requirement, and it cannot loosen a frequency the standard fixes itself, such as the 12-month scope confirmation in 12.5.2. An organisation-wide risk register does not satisfy 12.3.1 on its own; each qualifying requirement needs its own documented analysis with the elements 12.3.1 lists.