PCI DSS Risk Assessment: Targeted Risk Analysis Template and Worked Examples

PCI DSS v4.0.1 no longer asks for a single annual PCI DSS risk assessment. Since v4.0, risk analysis is done through targeted risk analyses (TRAs): short, documented analyses that each justify one decision for one requirement, such as how often you perform an activity where the standard lets you choose (Requirement 12.3.1), or how a customised control meets its objective (Requirement 12.3.2). Assessors have tested them since the future-dated requirements became mandatory on 31 March 2025.

If you came here looking for a “PCI DSS risk assessment template”, a TRA is the document you now need. Download our free PCI DSS targeted risk analysis template (Excel), then read on for what each field means, two worked examples and the mistakes a QSA is most likely to flag.

Key takeaways

• The v3.2.1 annual risk assessment (old Requirement 12.2) was replaced in v4.0 by targeted risk analyses under Requirement 12.3.
• You need a TRA for each requirement where you choose the frequency, and for each requirement met using the customised approach.
• Each TRA must identify assets, threats and likelihood and impact factors, and justify the result.
• TRAs must be reviewed at least every 12 months.
• A broader risk assessment is still good practice, and it feeds your TRAs.

What is a targeted risk analysis in PCI DSS?

A targeted risk analysis is a risk analysis scoped to a single PCI DSS requirement. Instead of rating risk across the whole business, it asks a narrow question, such as “how often do we need to review these logs to keep the risk acceptably low?”, and records the answer and the reasoning.

Requirement 12.3 in PCI DSS v4.0.1 has four parts:

The effect is to move risk analysis from a general annual document to specific decisions that an assessor can test against what actually happens.

Does PCI DSS v4.0.1 still require an annual risk assessment?

Not as a single organisation-wide exercise. Under v3.2.1, Requirement 12.2 required a formal risk assessment at least annually and after significant change. In v4.0, Requirement 12.2 covers acceptable use policies for end-user technologies, and risk analysis moved to Requirement 12.3.

That means a generic risk assessment template no longer meets the standard on its own. Your assessor will ask for the individual TRAs behind each flexible frequency and each customised control. TRAs are narrower than the old assessment, but more demanding: each one must reflect your environment, not generic threats.

What happened to the PCI DSS Risk Assessment Guidelines?

The PCI DSS Risk Assessment Guidelines that still appear at the top of search results are an information supplement the PCI SSC published in November 2012. They supported the annual risk assessment in PCI DSS v2.0 (Requirement 12.1.2, renumbered 12.2 in v3.0) and describe how to run an organisation-wide assessment with an established method, such as the three that v2.0 itself named: OCTAVE, ISO/IEC 27005 and NIST SP 800-30.

They predate v4.0, and the requirement they supported no longer exists. This is what replaced them:

The 2012 document is still sound background on risk methods for the wider risk assessment you will want anyway, but it is not evidence for any v4.0.1 requirement.

Which PCI DSS requirements need a targeted risk analysis?

Flexible-frequency requirements (12.3.1)

Several requirements let you decide how often something happens, provided you justify it with a TRA. They include:

Not every requirement will apply to you. List the ones in your scope, whether you validate with a Report on Compliance or an SAQ, and make sure each has a TRA. If you are unsure which SAQ applies, our free PCI compliance check suggests the likely one.

Customised approach (12.3.2)

If you meet any requirement using the customised approach, each one needs its own TRA, approved by senior management and reviewed at least every 12 months. The customised approach is only available through a Report on Compliance. Appendix E of the standard includes sample templates, and our guide to PCI DSS compensating controls explains how the customised approach differs from them.

What should a PCI DSS targeted risk analysis template include?

Requirement 12.3.1 sets out the elements every TRA must contain. A simple template, one per requirement, covers:

Our free targeted risk analysis template (Excel) sets out these fields as columns, with one row for each flexible-frequency requirement listed above, a status column for approvals and reviews, and both worked examples below filled in. The PCI SSC document library also includes guidance on targeted risk analysis with a sample template, which is worth reading alongside the standard.

What does a completed targeted risk analysis look like?

Example 1: log review frequency (10.4.2.1)

Requirement 10.4.2.1 lets you set how often to review logs from system components that are not covered by the daily review in 10.4.1.

• Assets: internal systems such as print servers and non-CDE workstations that are still in scope.
• Threats: an attacker using one of these systems as a foothold, with activity going unnoticed.
• Likelihood factors: the systems are not internet-facing, have hardened builds and are covered by endpoint detection that alerts in real time.
• Impact factors: they have no direct access to card data; a delay in review would slow detection of lateral movement.
• Result: weekly review of these logs, with automated alerting for defined high-risk events, keeps the risk acceptably low.

Example 2: payment terminal inspections (9.5.1.2.1)

A retailer with countertop card terminals in each store needs to decide how often staff inspect them for tampering and substitution.

• Assets: the terminals and the card data read by them.
• Threats: skimming overlays, tampered internals or a terminal swapped for a look-alike.
• Likelihood factors: terminals are tethered, sit in view of staff and are never left unattended; the retailer has had no incidents, but skimming is reported in its sector.
• Impact factors: every card used on a compromised terminal is exposed until the tampering is found.
• Result: a quick visual check by the shift supervisor at opening each day, plus a detailed monthly inspection of serial numbers and seals. Unattended kiosks elsewhere in the estate get their own, more frequent schedule.

In both cases the assessor will check that the reasoning is specific to your environment and that the chosen frequency is actually followed.

Who approves a TRA, and how often is it reviewed?

Each TRA should have an owner, an approver and a review date. In practice:

• Assign an owner for each TRA, usually the person responsible for the related control.
• Use one method across all TRAs so results are consistent and comparable.
• Get formal approval from someone with the authority to accept the risk; senior management for customised controls.
• Set review dates in your compliance calendar, at least every 12 months.
• Revisit after change. New systems, new threats or incidents can invalidate a TRA before its review date.
• Keep evidence that the chosen frequency is followed, such as log review records and inspection sheets.

Our PCI DSS business as usual guide shows how TRA reviews fit into a year-round compliance calendar.

Where does the wider risk assessment fit?

PCI DSS no longer mandates an organisation-wide risk assessment, but you still need one in practice. It tells you where your assets are, what threatens them and which controls matter most, and it gives each TRA a consistent basis. ISO 27001 requires one, and UK GDPR requires data protection impact assessments for high-risk processing.

A broader risk register can use a familiar structure: asset, threat, vulnerability, likelihood, impact, risk rating, owner, treatment and review date. Recognised methods such as NIST SP 800-30 or ISO/IEC 27005 give you a defensible way to score likelihood and impact consistently.

Technical inputs keep it grounded. Results from internal vulnerability scanning and PCI DSS penetration testing show real weaknesses, and Requirement 6.3.1 requires you to assign risk rankings to new vulnerabilities using industry sources and your own context.

What do assessors find wrong with targeted risk analyses?

The same problems come up repeatedly:

• Choosing a convenient frequency first and writing the justification afterwards
• Copying one generic TRA across several requirements
• Missing TRAs for requirements such as 11.6.1 or 9.5.1.2.1 that apply to the environment
• No evidence of approval or annual review
• Analyses that describe the threat in general terms but say nothing about your systems
• A frequency on paper that does not match what staff actually do

Each of these is easy to fix before an assessment and hard to explain during one.

Getting your TRAs reviewed

Targeted risk analyses are one of the newer areas of PCI DSS, and interpretations vary. Start with the free TRA template, then have the finished analyses checked before your assessor sees them. Sovereign Secure is a PCI SSC-approved QSA company. Through our PCI DSS consultancy we help clients draft and review TRAs during gap analyses and readiness reviews, so they hold up before your PCI compliance audit. For the rest of the v4.0.1 evidence an assessor will ask for, work through our PCI compliance checklist.