The PCI DSS Targeted Risk Analysis (12.3.1), Explained

The Targeted Risk Analysis, or TRA, is the connective tissue of PCI DSS v4.x. It is also one of the most misunderstood parts of the standard. Where the older versions of PCI DSS handed you fixed intervals for many periodic controls, v4.x shifts a large share of that decision onto you. When the standard now says a control must happen “at a frequency defined in the entity’s targeted risk analysis”, it is telling you to think, to document, and to defend your own reasoning. If you have been treating that phrase as a formality, this article will change how you approach it.

At Cianaa we assess businesses across New Zealand and Australia against the PCI DSS standard, and the TRA is now a recurring theme in every engagement. Below we set out exactly what Requirement 12.3.1 asks for, how it differs from the very different analysis required by 12.3.2, a full worked example, the mistakes we see most often, and a reusable template outline you can adopt straight away.

What a TRA is, and why v4.x introduced it

A Targeted Risk Analysis is a structured, documented piece of reasoning that determines how often a specific security control needs to be performed in your particular environment. It is “targeted” because it addresses one control at a time rather than your whole risk landscape. It replaces the one-size-fits-all intervals of earlier PCI DSS versions with a risk-based decision that fits your assets, your threats, and your operational reality.

The rationale is sound. A quarterly review interval that suits a large processor with thousands of accounts may be far too slow for a small merchant with a handful of privileged users, or unnecessarily aggressive for a component that carries very little risk. By asking you to perform a TRA, the Council pushes you to justify frequency rather than inherit it. That flexibility comes with an obligation: your reasoning must be written down, and it must hold up under assessment.

Requirement 12.3.1 applies to any requirement where the standard explicitly lets you choose how frequently a control is performed. For each such case you must perform and document a TRA. This is not optional, and it is not something a QSA can wave through on the basis of a verbal explanation.

The four things a 12.3.1 TRA must document

Every 12.3.1 analysis, regardless of which control it supports, must document four elements. Miss one and the analysis is incomplete.

1. The asset or assets being protected. Identify precisely what the control defends. Be specific: a payment page, a set of point-of-interaction (POI) devices, a class of privileged accounts, a category of removable media.
2. The threat or threats the control guards against. Name what could go wrong if the control were absent or too infrequent. Skimming malware, unauthorised script injection, credential compromise, undetected tampering.
3. The factors that contribute to the likelihood and/or impact of the threat being realised. This is the heart of the analysis. Consider exposure, historical incidents, the sensitivity of the data, the number and behaviour of the assets, and any compensating factors already in place.
4. An analysis that determines, and justifies, how frequently the control must be performed to adequately reduce the risk. The frequency is a conclusion, not a starting point. It must follow logically from the factors you listed.

On top of these four elements, each TRA must be reviewed at least once every 12 months. We return to that obligation at the end.

Which requirements point to 12.3.1 for their frequency

A number of PCI DSS v4.x requirements defer their interval to your TRA. The table below presents a representative subset. It is not an exhaustive list, so when you scope your programme, read each applicable requirement carefully to see whether it hands frequency to you.

Note the pattern. Each of these is a periodic activity where the “right” interval genuinely depends on context. That is precisely why the standard delegates the decision to you and asks you to record your working.

A worked example: Requirement 11.6.1 tamper detection frequency

Let us walk through a real analysis. Requirement 11.6.1 asks you to detect and alert on unauthorised changes to the security-impacting HTTP headers and script content of your payment pages as received by the consumer browser. The default expectation is at least every 7 days, but the requirement allows you to set the interval through a TRA. If you want to move away from weekly, or simply to confirm that weekly is appropriate, you must produce the analysis. For the broader client-side context, see our companion piece on client-side security under 6.4.3 and 11.6.1.

Asset being protected. The single hosted checkout page at checkout.example.co.nz, which renders the card-data entry form in the consumer’s browser and loads scripts from your own domain plus two third-party providers (an analytics tag and a fraud-scoring library).

Threat. A client-side attack (commonly called digital skimming or a Magecart-style attack) in which an adversary injects or modifies script on the payment page to harvest cardholder data directly from the browser, bypassing your server-side controls entirely.

Factors contributing to likelihood and impact. Consider each honestly:

• Exposure: the page is public-facing and directly captures primary account numbers, so it is a high-value target.
• Script surface: two third-party scripts sit outside your direct change control, widening the attack surface and reducing your visibility of changes.
• Change velocity: the page and its scripts change roughly once a month through planned releases, so unexpected changes stand out but do occur.
• Detection latency: any interval you choose is also your maximum blind window. If tampering happens the day after a check, that window is how long the skimmer runs unseen, harvesting live card data.
• Impact: a successful skim exposes full track-equivalent data at the point of entry, with severe financial, regulatory, and reputational consequences.
• Compensating factors: you enforce a strict Content Security Policy and subresource integrity on first-party scripts, which lowers, but does not remove, the likelihood of undetected injection.

Analysis and justified frequency. The impact is unequivocally high because live cardholder data is at stake. The likelihood is moderate: third-party scripts widen the surface, but your CSP and integrity controls constrain it. The decisive factor is detection latency. Because every day of undetected tampering equals a day of live data theft, a long interval is indefensible regardless of compensating controls. Given the high impact and the direct relationship between interval and exposure window, you conclude that detection must run at least every 7 days, matching the default, and you configure it to run daily on the checkout page specifically because that page carries the entire risk. You would document that a weekly interval is the ceiling, that daily is your chosen operating frequency, and that you will revisit the interval if the third-party script count or the CSP posture changes.

Notice what this produces: a frequency that a QSA can trace, step by step, from asset to threat to factors to conclusion. That traceability is the whole point.

How 12.3.2 is different

Requirement 12.3.2 is also called a Targeted Risk Analysis, and this shared name is the source of most confusion. The two are entirely separate exercises serving entirely different purposes.

Requirement 12.3.1, as we have seen, is about frequency. It answers “how often should this control run?” for controls where the standard lets you decide.

Requirement 12.3.2 is about equivalence. It is required for each requirement you choose to meet using the Customized Approach rather than the Defined Approach. When you use the Customized Approach, you are not following the prescriptive control the standard specifies; you are implementing your own control to meet the same objective. The 12.3.2 analysis must demonstrate that your customised control achieves protection equivalent to the defined-approach requirement and meets the Customized Approach Objective for that requirement. It is a rigorous justification that your alternative genuinely delivers the same security outcome.

So the two never overlap. A 12.3.1 TRA sets an interval for a control you are performing under the Defined Approach. A 12.3.2 TRA proves that a control you have redesigned under the Customized Approach is as strong as the original. Conflating them, for instance producing a frequency analysis when an equivalence analysis is required, is a finding waiting to happen.

Both 12.3.1 and 12.3.2 are future-dated requirements that became mandatory on 31 March 2025. If your programme has not caught up, read our note on the future-dated requirements now in force.

Common mistakes QSAs see

Across assessments, the same avoidable errors recur:

• Starting from the frequency. Deciding “quarterly” first and then reverse-engineering a rationale. The frequency must be the conclusion, not the premise.
• Skipping the factors. Naming the asset and threat but never analysing the likelihood and impact factors that actually drive the interval. This is the element assessors scrutinise most.
• One generic TRA for everything. A single document covering all your periodic controls in vague terms. Each control needs its own targeted analysis.
• Confusing 12.3.1 with 12.3.2. Producing the wrong type of analysis, or assuming one document satisfies both.
• Forgetting the annual review. Writing the TRA once and never revisiting it, so it drifts out of step with the environment.
• No link to operational reality. A frequency on paper that the operations team does not actually meet, which surfaces immediately when the QSA checks evidence of the control running.

A TRA template outline you can reuse

The PCI SSC has published an information supplement, “PCI DSS v4.x: Targeted Risk Analysis Guidance”, which includes templates for both the 12.3.1 and 12.3.2 analyses. We recommend obtaining it. In the meantime, the outline below captures the structure a defensible 12.3.1 TRA should follow:

• Header: the PCI DSS requirement addressed, the control in question, the author, the date completed, and the next review date.
• Asset identification: the specific asset or assets the control protects, described precisely.
• Threat description: the threat or threats the control guards against if it were absent or performed too infrequently.
• Likelihood factors: the elements that raise or lower the chance of the threat being realised in your environment.
• Impact factors: the consequences if the threat were realised, including data exposure and business effect.
• Existing compensating factors: any controls already in place that influence residual risk.
• Analysis and reasoning: the working that connects the factors above to a proposed frequency.
• Determined frequency and justification: the chosen interval and a clear statement of why it adequately reduces the risk.
• Approval: sign-off by an accountable owner.
• Review record: the dates and outcomes of each annual review.

The annual review obligation

Every TRA, whether under 12.3.1 or 12.3.2, must be reviewed at least once every 12 months. This is not a rubber stamp. The review asks whether anything has changed that should shift your conclusion: new assets, new threats, a change in data volumes, a new third-party integration, an incident, or a change to the compensating controls you relied on. If the environment has moved, the frequency may need to move with it. Build these reviews into your compliance calendar and keep dated evidence of each one, because an out-of-date TRA is treated as an incomplete one.

Frequently asked questions

Do I need a separate TRA for every applicable requirement?

Yes. Each requirement that defers its frequency to a TRA needs its own targeted analysis, because the assets, threats, and factors differ from one control to the next. A single blanket document does not satisfy 12.3.1.

Can I just keep the default frequency and skip the analysis?

No. Even where a default exists, such as the at-least-every-7-days baseline for 11.6.1, the requirement still expects a documented TRA to confirm that the interval you operate is appropriate for your environment. Choosing the default is a valid outcome, but it must be a justified one.

Is a 12.3.2 TRA required if I use only the Defined Approach?

No. Requirement 12.3.2 applies only to requirements you meet using the Customized Approach. If you rely entirely on the Defined Approach, you will still have 12.3.1 analyses for frequency, but no 12.3.2 equivalence analyses.

Who should own and approve the TRA?

Ownership should sit with someone accountable for the relevant control and its risk, typically within security or compliance, with formal sign-off recorded. The people who operate the control should be involved so that the chosen frequency is realistic and actually met in practice.

How Cianaa can help

As an independent PCI QSA practice serving New Zealand and Australia, Cianaa helps you build TRAs that are genuinely defensible, distinguish 12.3.1 from 12.3.2 correctly, and stand up to assessment. If you would like a review of your existing analyses or support in building them from scratch, get in touch with our team.