PCI DSS 12.3.1: For each PCI DSS requirement that specifies completion of a targeted risk analysis
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.
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. Several requirements let you define your own frequency instead of following a prescribed one, and each of those choices depends on a targeted risk analysis performed to the six elements listed here. Without it, the flexible option is not a choice you made, it 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 per requirement where you chose your own frequency, not a single combined document.
- 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 where you actually took the flexible option. Anti-malware scan frequency, some review cycles, and the 11.6.1 monitoring frequency are the common ones. If you took the prescribed frequency everywhere, this control has little to do.
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… |
← 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.