Targeted risk analysis under PCI DSS 4.x: what it is and how to write one

PCI DSS v4 introduced a kind of document that many organizations had never written before: the targeted risk analysis, often called a TRA. It sounds heavy, but a good TRA is usually a few pages long. This article explains what a TRA is, when you need one, and how to write one that an assessor will accept.

What is a targeted risk analysis?

Earlier versions of PCI DSS set fixed frequencies for many activities, such as reviewing certain logs daily. Version 4 lets organizations set some of these frequencies themselves, as long as they justify the choice. The TRA is that justification. As the Council puts it, “risk analysis is a foundational tool to help organizations identify and prioritize potential threats and vulnerabilities within their environment.”

There are two types, described in the Council’s TRA guidance published on 2023-11-28:

• Requirement 12.3.1: a TRA for requirements that allow flexibility in how often a control is performed.
• Requirement 12.3.2: a TRA for each requirement met with the customized approach, showing how your own control achieves the objective.

This article focuses on 12.3.1, which applies to most organizations. It was one of the future-dated requirements that became mandatory on 2025-03-31.

Which requirements call for a 12.3.1 TRA?

A TRA is only needed where the standard says the frequency is defined by the entity’s targeted risk analysis. Practitioners list the following requirements:

• 5.2.3.1: how often to evaluate systems considered not at risk from malware.
• 5.3.2.1: how often to run periodic anti-malware scans.
• 7.2.5.1: how often to review application and system account access.
• 8.6.3: how often to change passwords for application and system accounts.
• 9.5.1.2.1: how often to inspect payment terminals for tampering.
• 10.4.2.1: how often to review logs of lower-risk system components.
• 11.3.1.1: how to address vulnerabilities that are not high-risk or critical.
• 11.6.1: how often to check payment pages for unauthorized changes, if not weekly.
• 12.10.4.1: how often to train incident response staff.

Not every item will apply to you. A merchant with no payment terminals has no 9.5.1.2.1 TRA to write, for example.

What a 12.3.1 TRA must contain

Requirement 12.3.1 sets out the content. In summary, each TRA must identify the assets being protected, the threats the requirement guards against, and the factors that affect likelihood or impact, and must analyse how the chosen frequency addresses the risk. Each TRA must also be reviewed at least once every 12 months and updated when needed.

How to write one, step by step

1. State the requirement and the decision. For example: “Requirement 9.5.1.2.1. We inspect payment terminals at our three stores every week.”
2. Describe the assets. Which systems, devices or data are covered, and where they are.
3. Identify the threats. What could go wrong if the control were not performed? For terminals, think of skimming overlays or device substitution.
4. List the factors that affect likelihood and impact. Public access, staff presence, camera coverage, transaction volume, past incidents, tamper-evident seals.
5. Justify the frequency. Explain, in a few sentences, why the chosen frequency reduces the risk to an acceptable level. Higher exposure should mean more frequent checks.
6. Record approval and review. Who approved it, when, and when it will next be reviewed.

The Council provides sample templates in its document library. They are a good starting point.

Mistakes to avoid

• Copying a template without adapting it. Assessors look for facts specific to your environment.
• Working backwards from the easiest answer. A TRA that picks “annually” for everything without real reasoning will not hold up.
• Forgetting the review. A TRA nobody has looked at in two years will draw attention.
• Confusing a TRA with an enterprise risk assessment. A TRA is narrow and tied to one requirement. It does not replace your broader risk management.

Why it is worth doing well

A well-written TRA does more than satisfy the assessor. It forces a short, honest conversation about where your real risks are, and it gives you a defensible record if a decision is ever questioned. That is sensible governance practice, whether or not cards are involved.

See our PCI DSS overview for context, and our sample documents for examples of the documentation assessors expect. The Accel PCI portal helps track TRAs and their review dates, and KW Consulting can facilitate risk workshops and draft TRAs with your team. Contact us for help.

Sources

• PCI SSC blog: Just Published: PCI DSS v4.x Targeted Risk Analysis Guidance
• Compass IT Compliance: Maintaining targeted risk analyses for PCI DSS compliance