PCI DSS Targeted Risk Analysis (TRA): Required Elements

PCI DSS v4.x replaced the former organization-wide risk-assessment requirement with targeted risk analyses (TRAs). Two requirements define what must be documented: 12.3.1 (where the standard specifies a TRA, typically for activity frequency) and 12.3.2 (for each requirement met with the Customized Approach). This page lists only the elements those requirements specify — not a proprietary CyberSilo form layout.

Do not invent a mandatory layout: PCI DSS v4.0.1 Appendix E points to sample Controls Matrix and TRA templates on the PCI SSC website. Using those exact formats is optional; documenting the information they define is required and must be provided to the assessor.

Requirement 12.3.1 — Required Elements

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.

12.3.1 was a best practice until 31 March 2025 and is now mandatory (see the future-dated list). An enterprise-wide risk assessment is recommended in guidance but is not required by 12.3.1.

Where 12.3.1 Applies — Frequency-Caller Requirement IDs

These requirements explicitly call for a TRA performed according to the elements in 12.3.1 (typically to define how frequently an activity is performed, or an equivalent flexible process):

5.2.3.1 — frequency of periodic evaluations of system components identified as not at risk for malware
5.3.2.1 — frequency of periodic malware scans (when periodic scans are used to meet 5.3.2)
7.2.5.1 — frequency of periodic reviews of application and system account access
8.6.3 — frequency (and related complexity) for protecting application/system account passwords/passphrases
9.5.1.2.1 — frequency and type of periodic POI device inspections
10.4.2.1 — frequency of periodic log reviews for system components not covered by 10.4.1
11.3.1.1 — addressing other applicable (non–high-risk / non–critical) vulnerabilities based on the entity’s TRA
11.6.1 — payment-page change-and-tamper detection at least weekly or at the frequency defined in the entity’s TRA
12.10.4.1 — frequency of periodic training for incident response personnel

Always confirm the exact Defined Approach wording in PCI DSS v4.0.1 for your scope — do not treat this as “TRA for every PCI requirement.”

Requirement 12.3.2 — Required Elements (Customized Approach)

A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the Customized Approach, to include:

Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis).
Approval of documented evidence by senior management.
Performance of the targeted analysis of risk at least once every 12 months.

12.3.2 is immediate when the Customized Approach is used — it is not in the March 31, 2025 future-dated set. See the Customized Approach guide for Appendix D entity and assessor duties and eligibility limits (no SAQ entities; QSA/ISA + ROC; no compensating controls with Customized).

Practical Structure (Not a Prescribed Form)

You may organize evidence any way your GRC tool supports, as long as assessors can verify the required elements above. A workable checklist:

Requirement ID and whether the TRA is for 12.3.1 frequency or 12.3.2 Customized
For 12.3.1: assets, threats, likelihood/impact factors, justified frequency/process, last review date, update trigger
For 12.3.2: link to controls matrix, risk analysis, senior-management approval record, last review date
Evidence pointers (tickets, configs, test results) — separate from inventing extra mandatory fields

How CyberSilo Helps

CSA — store TRA records against the frequency-caller IDs and Customized controls
Gap assessment — flag missing TRAs before ROC / SAQ cycles
ThreatHawk — evidence for log-review frequency decisions under 10.4.2.1

Close TRA Gaps Before Assessment

Map 12.3.1 frequency callers and any Customized Approach 12.3.2 packages to owners and evidence — without inventing a form the standard does not require.

Request a PCI Gap Scan Customized Approach Guide

Frequently Asked Questions

Does PCI DSS require a TRA for every requirement?

No. 12.3.1 applies where a requirement specifies completion of a targeted risk analysis (typically for frequency flexibility). 12.3.2 applies only when the entity meets a requirement with the Customized Approach.

Must I use the PCI SSC sample TRA template layout?

No. In v4.0.1, sample templates live on the PCI SSC website. Format is optional, but the information defined in those templates must still be documented and provided to the assessor.

Is 12.3.1 future-dated?

Yes. 12.3.1 was a best practice until 31 March 2025 and is now mandatory. 12.3.2 (Customized Approach TRA) was effective immediately when Customized is used.

Customized Approach · 51 future-dated IDs · 12-requirement hub · What is PCI DSS v4.0.1 · Gap assessment · PCI DSS hub