PCI DSS Targeted Risk Analysis (TRA): What to Know

Introduction

As of March 31, 2025, Targeted Risk Analysis (TRA) will become a mandatory requirement for several controls in PCI DSS v4.0.1. This requirement affects both merchants and service providers equally, marking a significant change in compliance procedures.

Key Points About TRA Requirements

When is TRA Required?

Organizations must implement TRA if they:

• Use iFrames or URLs for third-party payment processing
• Handle cardholder data directly (processing, transport, or storage)
• Use non-P2PE-validated Point of Sale solutions
• Have systems declared exempt from anti-malware software
• Review access less frequently than every six months
• Use the customized approach
• Have payment channels eligible for SAQ types A, A-EP, C, and D

When is TRA Not Required?

Organizations generally don’t need TRA if they only use:

• Legacy systems (analog phone, fax, imprint machine)
• Stand-alone POI devices
• Network-isolated, Internet-connected POS devices
• Network-isolated virtual terminals
• P2PE solutions
• Qualify for SAQ types B, B-IP, C-VT, and P2PE

Detailed Requirements Breakdown

Anti-Malware (5.2.3.1 & 5.3.2.1)

• Applies to systems declared ‘not at risk for malware’
• Covers all system components, including network devices
• Defines frequency for malware scans and risk assessments

Access Management (7.2.5.1 & 8.6.3)

• Covers application and system account reviews
• Defines password change frequencies
• Applies to most entities using SAQ D

Physical Security (9.5.1.2.1)

• Focuses on POS/POI device inspection frequency
• Particularly relevant for card-present transactions
• Required for SAQ D users

Monitoring & Vulnerability Management (10.4.2.1 & 11.3.1.1)

• Establishes log review frequencies
• Sets remediation timelines for non-critical vulnerabilities
• Applies to SAQ A-EP, C, and D users

Website Security (11.6.1)

• Covers payment page tampering detection
• Required for SAQ A, A-EP, or D users
• Weekly checks can exempt from TRA requirement

Incident Response (12.10.4.1)

• Defines training frequency for IR personnel
• Applies to SAQ D users
• Recommended minimum annual training

Targeted Risk Analysis Implementation Requirements

Requirement	Purpose	Implementation Guidelines	Key Considerations
5.2.3.1	Define frequency for malware risk assessment	Review components marked as low malware risk • Include network devices • Monitor threat evolution speed	Faster evolving threats require more frequent assessment • Document justification for components deemed low risk • Include new threat intelligence in the assessment
5.3.2.1	Define malware scan frequency	If using continuous behavioral analysis, mark as N/A • Otherwise implement both real-time and periodic scans	Higher infection likelihood = more frequent scans • Higher potential impact = more frequent scans • Consider system criticality
7.2.5.1	Define access review frequency	Assess how often access privileges change • Consider the impact of potential account compromise	More frequent changes = more frequent reviews • Higher impact = more frequent reviews • Consider role criticality
8.6.3	Define password change frequency	Review password complexity • Assess encryption strength • Count the number of password holders	Stronger passwords + encryption = less frequent changes • More password holders = more frequent changes • Consider access criticality
9.5.1.2.1	Define POS/POI device inspection frequency	Assess supervision level • Consider transaction volume • Review incident history	Unattended devices need more frequent checks • High volume = more frequent checks • Prior incidents = more frequent checks
10.4.2.1	Define log review frequency	If using continuous monitoring, may skip TRA • Otherwise, assess component risk levels	Higher-risk components need more frequent reviews • Consider data access levels • Account for alert criticality
11.3.1.1	Define vulnerability remediation timelines	Assess exploitation likelihood • Evaluate potential impact • Set a priority-based schedule	Higher risk = faster remediation • Keep timeline under one year • Document justification for timeline
11.6.1	Define payment page tampering check frequency	If checking weekly or using continuous monitoring, skip TRA • Otherwise, assess page risk factors	Higher transaction volume = more frequent checks • More complex sites need more frequent checks • Consider impact of compromise
12.3.2	Manage TRA process	Use the PCI DSS template for customized approaches • Create separate analysis per control • Review annually	Document all approvals • Maintain analysis records • Update as needed
12.10.4.1	Define incident response training frequency	Consider incident types • Assess threat evolution rate • Account for team changes	Minimum annual training recommended • New threats = more frequent training • Document training justification

Implementation Process

Required TRA Elements (12.3.1)

1. Asset identification
2. Threat identification
3. Risk factor analysis
4. Frequency justification
5. Annual review of analysis
6. Updates as needed

Best Practices

• Document all analyses thoroughly
• Consider unique business threats
• Use industry threat data or historical loss data
• Review analyses annually
• Avoid working backward from desired frequencies
• Implement before assessment time

Documentation Options

• Create new processes based on PCI DSS requirements
• Integrate into existing risk evaluation processes
• Use PCI SSC’s published templates and guidance

SAQ Type Considerations

Scope Reduction

• Merchants can use SAQ eligibility for scope reduction
• Service providers need specific justification for scope reduction
• SAQ type alone doesn’t justify service provider scope reduction

TRA Requirements by SAQ Type

• SAQ A: Requirement 11.6.1
• SAQ A-EP: Requirements 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1, 11.6.1
• SAQ C: Requirements 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1
• SAQ D: All TRA requirements

Timeline and Compliance

• Mandatory implementation by March 31, 2025
• Current version: PCI DSS v4.0.1
• Annual reviews required for all TRAs