A targeted risk analysis (TRA) is a short, documented analysis that PCI DSS 4.0 uses in two places. Under Requirement 12.3.1, you need one for each requirement that lets you choose how often to do something. Nine requirements explicitly call for it, such as how often to review logs for lower-risk systems. Requirement 12.3.1 is a best practice until March 31, 2025, when it becomes mandatory. Requirement 12.3.2 covers something different: every requirement you meet through the customized approach, and it already applies. A sound 12.3.1 TRA identifies the assets and threats, weighs what drives likelihood and impact, justifies the frequency you chose, and gets reviewed at least every 12 months.
This guide focuses on 12.3.1, since that's the one most organizations will have to do, and walks through how to perform one.
What is a targeted risk analysis in PCI DSS 4.0?
PCI DSS 3.2.1 requires an annual, organization-wide risk assessment under Requirement 12.2. Version 4.0 drops that requirement and replaces it with targeted risk analyses tied to specific requirements. Instead of one broad document, you produce a focused analysis wherever the standard leaves a decision to you.
There are two kinds, and they're easy to mix up.
| Requirement 12.3.1 | Requirement 12.3.2 | |
|---|---|---|
| Purpose | Justify the frequency you choose where a requirement allows flexibility | Support each requirement met with the customized approach |
| Who needs it | Any entity with in-scope requirements that reference 12.3.1 | Only entities using the customized approach |
| When it applies | Best practice until March 31, 2025, then mandatory | Now, in any PCI DSS 4.0 assessment that uses the customized approach |
| Required content | Assets, threats, likelihood and impact factors, and a justified frequency | Everything in Appendix D, including at least a controls matrix and a risk analysis |
| Approval | Not specified in the requirement | Senior management approval required |
| Review | At least every 12 months, with updates when needed | Performed at least once every 12 months |
For 12.3.2, Appendix E2 of the standard includes a sample template. For 12.3.1, the standard lists what the analysis must contain but leaves the format and method to you.
Which requirements need a 12.3.1 targeted risk analysis?
Nine requirements in PCI DSS 4.0 explicitly say that their frequency or timing is set by a TRA performed according to 12.3.1.
| Requirement | What your TRA decides |
|---|---|
| 5.2.3.1 | How often to re-evaluate system components you've identified as not at risk from malware |
| 5.3.2.1 | How often to run periodic malware scans, if you use periodic scans to meet 5.3.2 |
| 7.2.5.1 | How often to review access by application and system accounts, and their privileges |
| 8.6.3 | How often to change passwords for application and system accounts |
| 9.5.1.2.1 | How often to inspect point-of-interaction (POI) devices, and what type of inspection to perform |
| 10.4.2.1 | How often to review logs for system components not covered by the daily reviews in 10.4.1 |
| 11.3.1.1 | How quickly to address vulnerabilities that aren't ranked high-risk or critical |
| 11.6.1 | How often the payment page change- and tamper-detection mechanism runs, if not at least once every seven days |
| 12.10.4.1 | How often to train incident response personnel |
All nine are themselves future-dated to March 31, 2025, so the TRA and the requirement it supports arrive together.
Requirement 12.3.1 is worded broadly. It covers any requirement that "provides flexibility for how frequently it is performed". If you find another place where you're choosing a frequency, talk to your assessor about whether they'll expect a TRA there too.
A TRA can't change a fixed frequency. For example, quarterly internal and external vulnerability scans remain quarterly, and a TRA won't justify stretching them.
What must a 12.3.1 targeted risk analysis include?
Requirement 12.3.1 says each TRA must be documented and include:
- Identification of the assets being protected
- Identification of the threats the requirement protects against
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized
- An analysis that determines how often the requirement must be performed to minimize the likelihood of the threat being realized, with a justification for that frequency
- A review of each TRA at least once every 12 months to confirm the results are still valid
- An updated analysis when the annual review shows one is needed
That's the whole specification. The rest is judgment, and your assessor will look at the quality of that judgment.
How do you perform a targeted risk analysis, step by step?
Step 1: Confirm which requirements apply to you
Go through the nine requirements and mark each one as applicable or not applicable, with a reason. A business with no card-present payments has no POI devices to inspect. A merchant that fully outsources its payment page may have a different answer on 11.6.1 than one that hosts its own. If you use continuous behavioral analysis for malware instead of periodic scans, 5.3.2.1 may not apply.
Step 2: Define the assets
List the specific system components, data or devices the requirement covers in your environment. "Servers" is too vague. "The 14 in-scope servers not covered by daily log review under 10.4.1" is useful. Group assets that share the same risk profile, since each group may end up with a different frequency.
Step 3: Identify the threats
Ask what the requirement exists to prevent or detect. For log reviews, that's unauthorized activity going unnoticed. For application account passwords, it's a credential being exposed and used long after it should have been changed. Be concrete about how the threat would play out in your environment: stolen credentials, insider misuse, an unnoticed misconfiguration, or a compromised supplier.
Step 4: Weigh the factors that drive likelihood and impact
This is the core of the analysis. Useful factors include:
- Exposure: Is the asset reachable from the internet, from the CDE, or only from a restricted network segment?
- Access: How many people and accounts can reach or change it? Is multi-factor authentication in place?
- Change rate: How often does the asset or its configuration change?
- Existing detection: Do automated alerts cover the same threat between reviews?
- History: What have past reviews, scans, audits or incidents found?
- Impact: What could an attacker reach or change from this asset, and how much account data is involved?
A simple high, medium and low scale is enough, as long as you define what each rating means and apply it consistently.
Step 5: Decide the frequency and justify it
Turn the analysis into a specific frequency for each asset group. The justification should follow directly from steps 3 and 4. A reviewer should be able to see why a higher-risk group gets a shorter interval.
It's fine to start from what you do today. Test it honestly against the analysis, though, and don't write the analysis to fit a conclusion you've already reached.
Step 6: Document, approve and assign owners
Record the analysis, the result and the date. Name an owner for both the TRA and the activity it governs. Requirement 12.3.1 doesn't explicitly require management approval, but getting sign-off from whoever owns the risk makes the decision stick and the evidence stronger.
Step 7: Review at least every 12 months and after significant change
Put the annual review on a calendar. Also treat it as due when something material changes, such as new connectivity to the CDE, a new payment channel, or a finding that suggests the frequency is too long. Keep a record of each review, including reviews that change nothing.
What does a completed targeted risk analysis look like?
Here's a simplified example for Requirement 10.4.2.1.
Suppose an organization's in-scope environment includes several internal servers that connect to the CDE but don't store, process or transmit account data, and don't perform security functions. There are four file servers and a software build server that deploys code into the CDE. None of them fall under the daily log review in 10.4.1.
- Assets: The four file servers and the build server.
- Threats: Misuse of stolen or shared administrator credentials to move toward the CDE, and unauthorized changes to the build server that could push altered code into the CDE.
- Likelihood factors: None of the servers are internet-facing. Administrative access requires MFA, and only three administrators have access. Automated alerts already flag failed logins and privilege changes.
- Impact factors: A compromised file server offers limited, filtered access toward the CDE. A compromised build server could change code running inside the CDE.
- Result: The build server's potential impact is high enough that the team reclassifies it as a critical system component. That moves it under the daily reviews in 10.4.1 and out of this analysis. File server logs are reviewed weekly, with automated alerts covering the highest-risk events between reviews.
- Review: Annually, or sooner if connectivity between these servers and the CDE changes.
This isn't a template to copy. It shows what assessors look for: specific assets, reasoning they can trace, and different outcomes for different risks.
What mistakes should you avoid?
- Boilerplate analysis. A TRA that could apply to any company won't persuade an assessor that it applies to yours.
- One conclusion for everything. If every asset group lands on the same frequency, check whether you actually analyzed the differences.
- Skipping the annual review. The review is part of the requirement, and a TRA without an owner tends to go stale.
Frequently asked questions
When does Requirement 12.3.1 become mandatory?
It's a best practice until March 31, 2025, and mandatory after that. The nine requirements that rely on it have the same date. Doing your first round of TRAs before then gives you time to act on the results.
Can a targeted risk analysis let us do something less often than PCI DSS requires?
Only where the requirement gives you that flexibility. Where the standard sets a fixed frequency, such as quarterly vulnerability scans, a TRA doesn't change it.
Do we need a separate document for each requirement?
Not necessarily. Many organizations keep all their TRAs in one document or register. Each applicable requirement still needs its own analysis covering every element of 12.3.1.
Do organizations that complete an SAQ need targeted risk analyses?
If your SAQ includes one of the requirements that relies on 12.3.1, you need the supporting TRA. Check your SAQ against the list above.
Next steps
- List the nine requirements that reference 12.3.1 and mark each as applicable or not applicable, with a reason.
- Pick one applicable requirement and complete a TRA using the steps above. Use it to settle your format and rating scale before you do the rest.
- Agree on owners and put the annual review on a calendar.
- Share a draft with your assessor well before your first PCI DSS 4.0 assessment. Their feedback is cheaper before the assessment than during it.
- If you plan to use the customized approach, treat 12.3.2 separately. It already applies, and Appendices D and E2 set out what it requires.