Targeted Risk Analysis (TRA) Under PCI DSS 4.0: How to Actually Write One That Holds Up

If there's one document I get sent for review more than anything else these days, it's a Targeted Risk Analysis that technically exists but wouldn't survive five minutes of real scrutiny. I understand why — the requirement sounds straightforward on paper, but I've watched capable security teams produce TRAs that are really just a paragraph of justification dressed up to look like analysis. During a PCI DSS audit, that gap gets noticed fast.

I want to walk through what a TRA actually needs to contain, where I see teams go wrong, and how to write one that a PCI-qualified security assessor will actually accept rather than send back with questions.

What a Targeted Risk Analysis Actually Is

A TRA is not a general security risk assessment. That's the first misunderstanding I clear up in almost every engagement. Under PCI DSS v3.2.1, organisations often satisfied risk assessment obligations with a broad, enterprise-wide review that touched on cardholder data somewhere in the mix but wasn't really built around it. PCI DSS 4.0 changed that model entirely.

A TRA is narrow by design. It's tied to a specific requirement, a specific control, a specific decision — not your whole environment. The question it answers is always some version of: given the assets we're protecting and the threats we actually face, what frequency or approach genuinely reduces the risk here? That specificity is exactly what makes it useful, and exactly what makes it harder to fake.

The Two Types of TRA You'll Actually Encounter

PCI DSS 4.0.1 defines two distinct TRA obligations, both sitting under Requirement 12.3, and confusing them is one of the more common mistakes I see during a PCI compliance audit.

The first, under Requirement 12.3.1, applies when a PCI DSS requirement gives you flexibility on how often something needs to happen — malware scan frequency, log review cadence, and similar periodic activities. If you want to define your own frequency rather than defaulting to the standard's baseline expectation, a TRA is what justifies that decision.

The second, under Requirement 12.3.2, applies specifically when you're using the Customised Approach instead of the Defined Approach to meet a requirement. Here, the TRA does more work — it has to demonstrate that your alternative control provides protection genuinely equivalent to what the prescribed control would deliver, and it must be paired with a Controls Matrix documented under Appendix E1, then formally approved by senior management before it counts.

Knowing which type you're writing matters, because the depth of justification a PCI-certified assessor expects differs meaningfully between the two.

The Four Elements Every TRA Must Contain

Requirement 12.3.1 spells out exactly what has to be in the document, and I treat this list as non-negotiable during any PCI QSA audit I run.

• Identification of the assets being protected — usually the cardholder data itself, stored, processed, or transmitted somewhere within the specific control's reach. Be precise here. “Our systems” isn't an asset identification; naming the actual data flow or repository is.

• Identification of the threat the requirement is protecting against — this is where I see the most generic writing. A TRA that says “cyberattacks” as the threat hasn't done the work. What specifically happens if this control fails or runs less frequently than expected?

• Identification of the factors affecting likelihood and impact — think about what makes the threat more or less probable in your specific environment. Transaction volume, exposure of the system to the internet, how many people have access, whether the data is tokenised already. This is where genuine analysis happens rather than boilerplate.

• The resulting analysis and justification for your chosen frequency or approach — this ties the first three elements together into an actual conclusion. It should read as reasoning, not just a stated outcome.

Skip any one of these and I'd flag it as incomplete, regardless of how polished the document looks.

Where Most TRAs Actually Fall Apart

I've reviewed enough of these now to see the same failure patterns repeat.

The threat section gets treated as a formality. Teams write something like “unauthorised access” without describing what that access would actually let an attacker do, which makes the rest of the analysis feel disconnected from a real scenario.

The likelihood and impact factors are copied from a template without adjustment. If your TRA for password rotation and your TRA for log review cite identical risk factors, that's usually a sign neither was genuinely thought through for its specific context.

The conclusion doesn't follow from the analysis. I sometimes see a TRA where the stated factors would logically support more frequent activity, but the conclusion lands on a longer interval anyway, with no explanation for the disconnect. That's exactly what gets challenged during a PCI DSS audit.

The TRA is written once and never revisited. PCI DSS requires an annual review at minimum, and if your environment changes materially in between — a new payment channel, a shift in transaction volume, new third-party integrations — the review needs to reflect that, not just get rubber-stamped on schedule.

A Practical Example: Log Review Frequency

Let me walk through one that comes up constantly. Requirement 10.4.2.1 requires log reviews at a frequency your organisation determines through a TRA, with a floor of at least weekly. Say your team wants to review logs weekly rather than daily.

The asset being protected is your logging data covering access to the cardholder data environment. The threat is delayed detection of unauthorised access or anomalous activity, which increases attacker dwell time and the scale of potential data exposure. The likelihood and impact factors might include your transaction volume, whether automated alerting flags high-severity events between manual reviews, and how segmented your CDE actually is. The resulting analysis then explains why weekly review, combined with automated real-time alerting for critical events, adequately manages that risk — not just that weekly “feels reasonable.”

That's the difference between a TRA that would survive review during a PCI QSA audit and one that's really just an assertion with a heading on it.

Should You Use the Council's Templates

The PCI Security Standards Council publishes sample templates — one for activity frequency TRAs and a separate one, under Appendix E2, to support Customized Approach documentation. Neither is mandatory. You're free to document a TRA in any format, provided every required element from 12.3.1 is genuinely addressed.

In my experience, most organisations are better off starting from the Council's template rather than building from scratch, simply because it forces you through each required element in sequence. Where I see value added is in customising the questions honestly for your actual environment rather than filling in generic answers just to complete the form.

Working With Your Assessor Before, Not During, the Audit

TRAs are meant to be completed before your assessor arrives, not produced reactively once questions start. Bringing your PCI QSA services provider into the conversation early — during a gap assessment rather than mid-audit — tends to save real time, because an experienced PCI DSS QSA company will usually tell you upfront which of your periodic controls actually need a documented TRA and which don't.

Not every requirement needs one. TRAs apply specifically where PCI DSS gives flexibility on frequency or approach; fixed, prescriptive requirements don't leave room for this kind of justification, and writing one there is wasted effort.

Getting This Right Before Your Next Assessment

If you're preparing for an upcoming PCI compliance audit, I'd start by listing every periodic control in your environment where you've deviated from a strict interpretation of the standard's baseline frequency, and confirm each one has a genuinely reasoned TRA behind it — not a copied template with the dates changed. Pair that with an honest annual review process, and make sure whoever owns each TRA can actually explain the reasoning behind it in conversation, not just point to the document.

At Accorp Partners, this is one of the areas we spend real time on during readiness work, because a well-written TRA does more than satisfy an assessor — it forces genuinely useful thinking about where your actual risk sits.

Frequently Asked Questions

Q: What is a Targeted Risk Analysis under PCI DSS 4.0?
It's a documented, requirement-specific analysis that justifies the frequency or approach an organisation uses to meet a PCI DSS control, based on the assets, threats, and risk factors involved.

Q: What's the difference between a 12.3.1 TRA and a 12.3.2 TRA?
A 12.3.1 TRA justifies the frequency of a periodic activity. A 12.3.2 TRA supports the Customized Approach, demonstrating an alternative control provides equivalent protection to the defined requirement.

Q: Do I have to use the PCI Council's TRA template?
No. Any format is acceptable as long as it includes all four elements required under Requirement 12.3.1: assets, threats, likelihood/impact factors, and a justified conclusion.

Q: How often must a TRA be reviewed?
At least once every 12 months, with an updated analysis performed if the review identifies a material change.