PCI DSS 12.3.1: Wherever the standard lets you choose your own frequency, you must write a risk analysis that justifies the frequency you chose, and review it every 12 months.
PCI DSS v4.0.1 control 12.3.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 12.3.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.3
For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.
Summary
Wherever the standard lets you choose your own frequency, you must write a risk analysis that justifies the frequency you chose, and review it every 12 months.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 12.3.1 | Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that specifies completion of a targeted risk analysis, and that the process includes all elements specified in this requirement. |
This is the control that makes the flexible options elsewhere in the standard actually available. Nine requirements take a frequency or timescale from a targeted risk analysis: 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1 and 12.10.4.1. Each analysis must cover the six elements listed here. Some apply only in circumstances, and 11.6.1 and 5.3.2.1 each offer a route without one; where one applies, a frequency with no analysis behind it has no basis and is a gap. 11.6.1 is the clearest example: monitor weekly, or monitor at your own frequency and produce this analysis.
What to prepare
- One targeted risk analysis for each requirement that specifies one, not a single combined analysis.
- Each analysis covering all six elements: the asset, the threat, the factors affecting likelihood and impact, the justification for the frequency chosen, evidence of review within 12 months, and any resulting update.
- A list mapping each flexible requirement to its analysis, so an assessor can find them.
How to implement it
1. Start by listing which of the nine requirements apply to you. 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1 and 12.10.4.1 each take a frequency or timescale from a targeted risk analysis. Some apply only in circumstances, such as 5.2.3.1 to components judged not at risk from malware and 9.5.1.2.1 to POI devices, and 11.6.1 (monitoring at least weekly) and 5.3.2.1 (continuous behavioural analysis instead of periodic scans) can be met without one. The rest need an analysis wherever they apply.
2. Write one analysis per decision. The elements are specific to a threat and an asset, so a single organisation-wide risk assessment does not satisfy this. It is a narrow document about one frequency choice.
3. Make the justification connect the frequency to the threat. The fourth element asks how the chosen frequency minimises likelihood or impact. "Quarterly is operationally convenient" is not that; "the exposure window this creates is acceptable because of these compensating detections" is.
4. Diarise the 12-month review. The fifth and sixth elements are about review and update, so an analysis written once and never revisited fails two of six elements even if the original was excellent.
Where this commonly fails
- Taking a flexible frequency because it is easier and never writing the analysis, which converts a permitted choice into a finding.
- One enterprise risk assessment offered for every flexible requirement, when the control asks for a targeted analysis per requirement.
- An analysis with no review date, failing the 12-month review element regardless of its content.
Related controls
Others in section 12.3:
| Control | What it requires |
|---|---|
| 12.3.2 | A targeted risk analysis is performed for each PCI DSS requirement that the entity meets… |
| 12.3.3 | Cryptographic cipher suites and protocols in use are documented and reviewed at least once… |
| 12.3.4 | Hardware and software technologies in use are reviewed at least once every 12 months… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 12.2.1 · All controls · 12.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.