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)
- Asset identification
- Threat identification
- Risk factor analysis
- Frequency justification
- Annual review of analysis
- 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
Disclaimer
The views and opinions expressed in this article are solely my own and do not necessarily reflect the views, opinions, or policies of my current or any previous employer, organization, or any other entity I may be associated with.
