The Questions Surrounding PCI Requirement 12.3.1
As organizations complete their transition into the future-dated requirements of PCI DSS 4.0, which became effective on March 31, 2025, one control continues to generate questions during assessments: Requirement 12.3.1.
At first glance, the requirement looks like something most organizations already do. Many companies have mature enterprise risk management programs, annual cybersecurity risk assessments, and detailed risk registers. Because of that, teams often assume they are already covered.
However, Requirement 12.3.1 is testing something much more specific than a global or enterprise annual risk assessment. It is focused on targeted risk analysis that is tied directly to individual PCI DSS requirements. Understanding that distinction is the key to getting this requirement right.
What Requirement 12.3.1 is Actually Testing
Requirement 12.3.1 applies to each PCI DSS control that explicitly requires the completion of a Targeted Risk Analysis (TRA). These controls allow organizations to define the frequency, scope, or implementation approach based on their specific risk environment rather than following a fixed cadence. In PCI DSS v4.0, the requirements that call for a documented TRA include 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, 12.3.2, and 12.10.4.1. When organizations choose to adjust the defined frequency or method within these controls, Requirement 12.3.1 mandates that the decision be supported by a documented risk analysis that evaluates the threat environment, business impact, and effectiveness of the proposed approach. This ensures that flexibility in implementation does not weaken security expectations within the Payment Card Industry Data Security Standard (PCI DSS) framework.
The intent is not to duplicate your enterprise risk assessment. Instead, PCI DSS expects a focused, requirement-level evaluation that explains why your defined frequency or process is appropriate for your specific cardholder data environment.
Required Elements of a PCI Targeted Risk Analysis
For each applicable PCI requirement that requires a TRA, the documentation must include several core components.
One
The analysis must identify the assets being protected. This means clearly defining what systems, components, or asset groups the control applies to. Importantly, this does not require listing every individual server or system inside the TRA document itself. It is completely acceptable to reference an authoritative inventory, such as a maintained list of in-scope system components, or to define logical asset groups. Examples include all in-scope servers supporting the cardholder data environment, all administrative workstations with CDE access, or all hosted infrastructure components included in PCI scope. What matters is that the TRA clearly ties to the relevant portion of the PCI-defined scope and that the scope reference is defensible.
Two
The TRA must identify the threats the requirement is designed to protect against. This cannot be implied. The analysis should explicitly describe the risk the control mitigates. Depending on the requirement, that may include threats such as unauthorized access, malware introduction, credential compromise, exploitation of misconfiguration, or data exfiltration. The documentation should demonstrate that the organization understands the purpose of the control in the context of protecting cardholder data.
Three
The TRA must evaluate factors affecting likelihood and or impact. This is often where documentation becomes too generic. The analysis should consider real environmental drivers such as internet exposure, use of remote administration tools, complexity of infrastructure, third-party connectivity, transaction volume, sensitivity of stored data, or visibility to attackers. The goal is to show that the organization considered its specific operating environment when determining risk, rather than copying boilerplate language.
Four
The organization must provide a documented justification showing how the defined frequency or process minimizes risk. This is one of the most common areas for assessment findings. If a PCI requirement allows a company to determine how often an activity occurs, the TRA must clearly explain why that chosen cadence is appropriate. For example, increased frequency might be justified by elevated threat activity or prior findings. A reduced frequency might be justified by strong compensating controls, automation, or continuous monitoring capabilities. The explanation must connect directly to the risk factors identified earlier in the analysis.
Final
The TRA must be reviewed at least annually and updated as needed based on that review. This means there must be evidence that the organization revisits its rationale and evaluates whether environmental changes, new threats, scope adjustments, or technology changes require updates. A one-time document created to satisfy an assessment will not meet the requirement.
The Most Common Gap We Are Seeing with 12.3.1
The most frequent issue under Requirement 12.3.1 is not the absence of risk management. It is the absence of PCI-specific traceability.
Organizations often rely on an enterprise risk methodology that does not explicitly address PCI-targeted risk analysis with the required elements. In many cases, the enterprise assessment evaluates overall cyber risk posture but does not map clearly to individual PCI controls that require a TRA. When an assessor asks to see the TRA for a specific requirement, teams struggle to demonstrate that the required components are documented in a control-specific format.
If the enterprise methodology has not been explicitly extended to address PCI-specific TRAs with these elements, the organization should either formalize a standalone PCI TRA procedure or update the existing risk methodology to clearly map to Requirement 12.3.1. The key is clarity, documentation, and direct linkage to PCI requirements.
Direct Guidance from PCI SSC
The PCI Security Standards Council provides a helpful sample template titled PCI-DSS-v4.x-Sample Template TRA Activity Freq. While use of the template is not mandatory, it offers valuable insight into how assessors expect the documentation to be structured and what level of specificity is appropriate. Reviewing that template can help organizations calibrate their documentation before an assessment.
FAQ on PCI Requirement 12.3.1
Is Requirement 12.3.1 the same as our annual enterprise risk assessment?
No. While your enterprise risk assessment may provide useful input, Requirement 12.3.1 requires targeted, requirement-specific analysis that directly support PCI controls calling for a TRA. Unless your enterprise methodology explicitly addresses those PCI elements, it likely will not fully satisfy this requirement on its own.
Do we need a separate document for every single PCI requirement?
You only need targeted risk analysis for requirements that explicitly state a TRA is required. Not every PCI DSS requirement calls for one. However, where it is required, the documentation must clearly align to that specific control.
Do we have to list every individual system within the TRA?
No. You may reference a maintained authoritative inventory or define asset groups, such as all in-scope servers supporting the cardholder data environment or all administrative workstations with CDE access. The important factor is that the TRA clearly ties back to PCI-defined scope and that the reference is defensible.
What is the most common audit issue related to 12.3.1?
The most common findings related to Requirement 12.3.1 involve weak or incomplete documentation around the Targeted Risk Analysis itself. Assessors frequently see missing reasoning for the defined control frequency. Another common issue is organizations relying on broader enterprise risk documentation that does not clearly map to the specific requirements of the Payment Card Industry Security Standards Council framework.
Our team also commonly sees situations where a company has completed a Targeted Risk Analysis, but the supporting evidence and outcomes of that analysis are not clearly documented. For example, the TRA may state a decision about control frequency or monitoring approach, but the artifacts that support that decision, such as threat considerations, operational constraints, or validation of compensating safeguards are missing or difficult to produce during an assessment. Without clear documentation tying the analysis to the resulting control implementation, organizations can struggle to demonstrate that their TRA fully satisfies PCI DSS expectations.
What happens if we do not have TRAs documented now that the future-dated requirements are effective?
Since the future-dated requirements in PCI DSS 4.0 became effective on March 31, 2025, the required TRAs must now be in place. If they are missing or insufficient, this can result in non-compliance findings and potential delays in issuance of a Report on Compliance or Attestation of Compliance until remediation is completed.
Final Thoughts on PCI Requirement 12.3.1
Requirement 12.3.1 is not asking organizations to reinvent risk management. It is asking for discipline and specificity. PCI DSS expects targeted, documented analysis that clearly demonstrates why certain control frequencies or processes are appropriate for your cardholder data environment.
Organizations that treat targeted risk analysis as structured; requirement-level evaluations tied directly to PCI controls are navigating assessments with far fewer surprises. Those that assume their enterprise risk program automatically satisfies the requirement are the ones most often fielding additional questions. Given how frequently this control is scrutinized under PCI DSS 4.0, validating your TRA approach before your next assessment is a practical and worthwhile step.
We Can Help
Tevora’s experienced experts can answer any questions about meeting PCI and would welcome the opportunity to help you meet compliance standards. Give us a call at (833) 292-1609 or email us at [email protected].
