Maintaining Targeted Risk Analysis (TRAs) for PCI DSS Compliance

Every organization that processes, stores, or transmits cardholder data is required to protect it. That much is well understood. What is less understood, and where many organizations quietly fall short, is how they justify specific risk-based decisions inside their compliance program. That is exactly what a Targeted Risk Analysis (TRA) is designed to address.

PCI DSS v4.0 introduced TRAs as a formal requirement, and they carried forward into the current standard, PCI DSS v4.0.1, which has been the only active version since v4.0 was retired on 31 December 2024. If your organization is subject to PCI DSS, understanding what a TRA is, when it applies, and how to maintain it over time is foundational to your program.

A note on terminology: The PCI SSC uses the term “Targeted Risk Analysis,” not “Targeted Risk Assessment.” Both terms reduce to the same acronym, and you will hear them used interchangeably in the wild. Still, every formal reference in PCI DSS v4.0.1 (Requirements 12.3.1 and 12.3.2, the TRA Guidance Information Supplement, and the Sample Template: TRA for Activity Frequency) uses “analysis.” Using the standard’s actual language matters when your documentation lands in front of a QSA.

What Is a Targeted Risk Analysis?

A TRA is a structured evaluation tied to a specific PCI DSS requirement, not to your entire cardholder data environment (CDE). That distinction matters. A TRA does not sweep across your CDE the way an enterprise-wide risk assessment would. It zooms in on a single requirement, one control, one activity, one decision, and answers a narrow question: given the assets we are protecting and the threats we face, what frequency or implementation approach adequately mitigates the risk?

PCI DSS v4.0.1 defines two distinct TRA obligations that are often confused in practice. Both live in Requirement 12.3, but they apply to different situations and have different elements.

TRAs Under Requirement 12.3.1: Justifying Activity Frequency

Several PCI DSS requirements use the word “periodically” rather than specifying a frequency. In those cases, the standard intentionally hands the decision to the entity, but only on the condition that the entity performs a TRA to justify the cadence it selects.

Requirements where 12.3.1 TRAs commonly apply include:

• 5.2.3.1: frequency of evaluating system components not at risk for malware

• 5.3.2.1: frequency of periodic anti-malware scans

• 7.2.5.1: frequency of access reviews for application and system accounts

• 8.6.3: frequency of changes to passwords/passphrases for application and system accounts

• 9.5.1.2.1: frequency of POI device inspections

• 10.4.2.1: frequency of log reviews for components not handled by 10.4.1

• 11.3.1.1: addressing applicable vulnerabilities not ranked high-risk or critical, based on the entity’s vulnerability risk rankings

• 11.6.1: frequency of payment page change-and-tamper detection (alternative to the defined seven-day cadence)

• 12.10.4.1: frequency of incident response training updates

The PCI SSC’s Targeted Risk Analysis Guidance (November 2023) publishes suggested baseline frequencies for each of these sub-requirements. These are not binding. Entities must still document their own TRA, but it provides a useful reference point for analysis.

Examples from the guidance:

• Daily for 5.3.2.1 (periodic anti-malware scans)

• Every six months for 7.2.5.1 (application/system account access reviews) and 5.2.3.1 (re-evaluating components not at risk for malware)

• Every three months for 8.6.3 (application/system account credential changes)

• Monthly for 9.5.1.2.1 (POI device inspections)

• Weekly for 10.4.2.1 (log reviews) and 11.6.1 (payment page tamper detection)

• Annually, plus at the start of employment for 12.10.4.1 (IR training).

Whatever cadence an entity selects, the supporting TRA must justify that decision against the entity’s risk environment.

A common misconception is that TRAs can be used to perform an activity less frequently than PCI DSS-defined frequencies allow. That is not correct. Per the PCI SSC’s TRA Guidance, if a requirement states a specific frequency, an entity must perform the activity at least at that frequency to meet the requirement. A TRA cannot extend a defined cadence. Conversely, if an entity wants to perform an activity more frequently than a requirement states, no TRA is required.

The 12.3.1 TRA is reserved for sub-requirements in which the standard explicitly defers the frequency decision to the entity. (Requirement 11.6.1 is the hybrid case: the standard offers “at least once every seven days” or a frequency defined via TRA. Either path satisfies the requirement.)

TRAs Under Requirement 12.3.2: Supporting the Customized Approach

The second use case is more involved. When an entity chooses to meet a PCI DSS requirement using the Customized Approach rather than the Defined Approach, it must perform a separate TRA for each such requirement. This TRA accompanies a Controls Matrix (per Appendix E1) and must be approved by senior management.

The Customized Approach allows an entity to design alternative controls that meet the requirements stated in the Customized Approach Objective. The 12.3.2 TRA is the analytical backbone of that justification. Without it, the Customized Approach is not available to you.

The Required Elements of a 12.3.1 TRA

The standard prescribes exactly what a 12.3.1 TRA must contain. These are not general risk-assessment best practices borrowed from NIST SP 800-30. Rather, they are the specific elements your QSA will look for:

1. Identification of the assets being protected.

2. Identification of the threats the requirement is protecting against.

3. Identification of factors that contribute to the likelihood and/or impact of those threats being realized.

4. A resulting analysis that determines and justifies how the frequency or process the entity has selected minimizes that likelihood and/or impact.

5. Review of each TRA at least once every 12 months to determine whether the results remain valid.

6. Performance of updated analyses when needed, based on the annual review or upon changes that could impact risk.

The annual review and the change-driven review are independent triggers. You must review at least every 12 months, and whenever something materially changes, not only when both conditions are met.

Two layers of documentation are required, not one. Requirement 12.3.1’s testing procedure directs the assessor to examine both your documented policies and procedures defining the TRA process and each TRA. In practice, that means an entity needs a documented TRA methodology (covering how TRAs are scoped, performed, reviewed, and approved) in addition to the specific TRAs produced for each applicable requirement.

Mandatory Dates: When TRAs Became Assessable

When v4.0 was first published, both 12.3.1 and 12.3.2 were marked as “best practice until 31 March 2025.” Many organizations correctly read that as a runway to build out their TRA program. As of March 31, 2025, both requirements became fully mandatory and assessable. If you enter an assessment now, your QSA will test 12.3.1 and 12.3.2 as in-scope requirements rather than as forward-looking practices.

Common Mistakes Organizations Make with TRAs

In our work with organizations across financial services, retail, and hospitality, we consistently see the same patterns. Here are the mistakes that create the most risk during an assessment.

• Treating the TRA as a one-time exercise: A TRA completed during implementation and never revisited is not compliant. The annual review is a hard requirement, and change-driven reviews are layered on top of it.

• Scoping too broadly: The word “targeted” matters. A TRA written to cover the whole CDE has lost its target. A well-scoped TRA addresses one specific requirement and develops the analysis with the precision that single-purpose focus allows.

• Confusing 12.3.1 with 12.3.2: Many organizations write a single TRA template and apply it across both contexts. That tends to fail in two directions: the 12.3.1 TRAs end up over-engineered with Customized Approach elements they don’t need, and the 12.3.2 TRAs end up missing the Controls Matrix, senior management approval, and the required evidence of testing.

• Relying on likelihood estimates without evidence: A TRA that assigns likelihood without a documented rationale will not satisfy a QSA. Evidence can come from historical incidents, threat intelligence, penetration testing findings, vulnerability scan data, or industry benchmarks, but it must come from somewhere.

• Skipping the justification of the chosen cadence or approach: This is the heart of a 12.3.1 TRA. The required output is not just a risk rating; it is a documented explanation of why the entity’s chosen frequency or process adequately addresses the identified risk. A TRA that stops at threat identification is incomplete.

How to Maintain TRAs Over Time

Maintaining TRAs for PCI DSS compliance is an ongoing operational responsibility, not a pre-audit task. Here is a practical framework:

• Assign ownership: Every TRA should have a named owner responsible for keeping it current. Without ownership, reviews do not happen.

• Define a review trigger list: Any time a new system enters the CDE, a vendor relationship changes, an incident occurs, or a new threat is identified, the relevant TRAs should be reviewed.

• Set a maximum review interval: Annual review is required regardless of changes. If your last review predates last year’s audit, that is a problem.

• Document every review: Even a “no changes needed” outcome should be documented with a date, reviewer name, and conclusion. This creates the audit trail your QSA will ask for.

• Integrate TRA reviews into your security calendar: The strongest programs schedule TRA reviews alongside vulnerability scans, access reviews, and vendor assessments, not as isolated documents.

TRAs and the Customized Approach: What 12.3.2 Actually Requires

If your organization is using or considering the Customized Approach under PCI DSS v4.0.1, your 12.3.2 TRA is one piece of a larger documentation package. The following represents the full set of artifacts you need:

• A Controls Matrix describing each customized control, the requirement it addresses, the Customized Approach Objective it meets, the threats it counters, the assurance the entity has that the control is effective, and the maintenance procedures.

• A Targeted Risk Analysis (per 12.3.2) for each requirement met with the Customized Approach.

• Approval of all documentation by senior management.

• Evidence that the customized control has been tested for effectiveness.

• Annual refresh of both the Controls Matrix and the TRA.

Note that the Sample Templates published by the PCI SSC are optional in form but mandatory in content. Whatever format you use, the information they capture must be documented and provided to your assessor.

When to Bring in a QSA

For organizations with mature PCI DSS programs, building and maintaining TRAs internally is achievable. For organizations new to v4.0.1 or using the Customized Approach for the first time, working with a QSA early makes a meaningful difference. The Customized Approach is documentation-intensive, and rejected justifications can derail an assessment timeline.

A QSA brings an external perspective on whether your TRAs are structured correctly, whether your risk analysis methodology is defensible, and whether your documentation will hold up under audit. Identifying gaps before the formal assessment is always cheaper than discovering them during it.

At Compass IT Compliance, we work with organizations at every stage of the PCI DSS journey, from initial scoping and TRA development to full QSA assessments and ongoing compliance support. If you are unsure whether your TRAs are ready for your next assessment, we are here to help.

Final Thoughts

TRAs signal a meaningful shift in PCI DSS v4.0.1 from rigid, prescriptive checklists to thoughtful, evidence-based risk management. That shift is good for the industry. It is also more demanding.

Treat TRAs as living documents that are maintained, owned, and evidence-based, and PCI DSS v4.0.1 assessments get easier while your security posture genuinely improves. Treat them as a pre-audit checkbox, and you will revisit the same gaps year after year. The choice is yours. We are here when you are ready to make it count.

Ready to Review Your TRAs?

TRAs are one of the most commonly under-documented areas of PCI DSS, and they are now fully assessable. If yours have not been reviewed in the past 12 months, or if you have never built one for a Customized Approach control, you have a gap worth closing before your next assessment.

Compass IT Compliance offers PCI DSS readiness assessments, TRA development and review, Customized Approach documentation support, and full QSA services. Our PCI Compliance Specialists have guided organizations through every stage of the transition, and we can tell you in a single conversation whether your program is audit-ready or audit-exposed.

Contact us today to start the conversation.