What is a TRA and why do I need it?
Targeted Risk Analysis (TRA) is not just a best practice; it’s crucial until March 31, 2025. After this date, it becomes a requirement for several controls across many assessment types. This shift is significant because it applies equally to merchants and service providers, ensuring everyone is prepared for the changes ahead.
If you’re tired of sifting through unhelpful blogs that don’t simplify your compliance efforts, then this blog is specifically crafted for you. It provides clear, practical guidance on Targeted Risk Analysis (TRA) requirements and best practices.
Topics include:
- Do I need a TRA?
- Which Requirements? High View
- Common Implementations
- TRA per SAQ Type
- Defining the TRA Process
Rest assured, this information is current and relevant to the Payment Card Industry Data Security Standard (PCI DSS) version 4.0.1 and reporting templates version r1 from December 2022. I’ve addressed the most common questions about TRAs, but remember, your unique compliance obligations may vary.
Do I need a TRA?
Just because a PCI DSS report is a full ROC or SAQ type D does not mean that TRAs must be applied. TRA requirements are tied to other requirements that may or may not apply to a specific organization. If the organization’s scope is such that none of the PCI DSS requirements that reference Requirement 12.3.1 are in scope, then a TRA will not be required.
TRAs are required if:
- Using an iFrame or URL to redirect to a third-party payment processor
- Directly processing, transporting, or storing cardholder data, including mail order payments, call center payments, mobile device payments, eCommerce payments, viewing cardholder data online, and much more
- Utilizing Point of Sale (POS) solutions that are not Point-to-Point Encryption (P2PE)-validated
- Declaring some system types as not requiring anti-malware software
- Periodically reviewing access less often than every six months
- Utilizing the customized approach
- Having payment channels eligible for SAQ types A, A-EP, C, and D
Merchants qualifying for SAQ types B, B-IP, C-VT, and P2PE should not require TRAs. It takes only one in-scope activity in order to require a TRA, but the following activities or systems might not require TRAs:
- Legacy: analog phone, fax, imprint machine
- Stand-alone POI device
- Network-isolated, Internet-connected POS devices
- Network-isolated virtual terminals
- P2PE solutions
The ‘TRA per SAQ’ type section below details other considerations, especially for PCI DSS service providers.
Which Requirements? High View
I want you, fearless reader, to communicate TRAs adeptly to different audiences. For this reason, the following information summarizes the requirements for executives; implementation details follow below.
There are 11 total PCI DSS controls summarized in the short table below. Keep reading for the full details and how to define the TRA process.
| Requirement | Does it apply? |
| 5.2.3.1 | This is applicable for most entities using SAQs A-EP, C, and D if declaring some components to be ‘not at risk for malware’. PCI DSS version 4.0.1 drops the previous language of “particularly personal computers and servers” and applies to all system components, including network devices, which must be evaluated for susceptibility to malware. |
| 5.3.2.1 | This applies to many entities using SAQs A-EP, C, and D that perform real-time and periodic malware scans rather than continuous behavioral analysis of systems or processes for malware. Endpoint protection is advancing so rapidly that this will shift over time to fewer entities. |
| 7.2.5.1 | This applies to many entities using SAQ D. This requirement applies to all application and system accounts and related access privileges. |
| 8.6.3 | This applies to most entities using SAQs A-EP, C, and D. This requirement applies to any organization using password or passphrase authentication on application or system accounts. |
| 9.5.1.2.1 | This is applicable to most entities conducting card-present transactions via a POI device using SAQ D. This requirement applies to periodic tamper checks of POI devices. |
| 10.4.2.1 | This applies to all entities where monitoring logs are in scope using SAQ A-EP, C, and D. This requirement applies to log review frequency for logs that do not fall into categories requiring daily reviews. |
| 11.3.1.1 | This applies to all entities with system components in scope for internal vulnerability scans using SAQ D. This requirement applies to vulnerabilities identified during internal vulnerability scans that are not ranked as critical or high risks. |
| 11.6.1 | This is applicable for entities with payment pages or that embed third-party payment pages (e.g., via iframe) using SAQ A, A-EP, or D. This requirement applies to website tamper detection mechanisms. |
| 12.3.2 | This applies only to entities using the customized approach rather than the defined approach most organizations use for PCI DSS compliance. This requirement applies to each requirement that uses the customized approach. |
| 12.10.4.1 | This applies to all entities using SAQ D. This requirement applies to Incident Response training. |
Common Implementations
Now that you know which requirements are applicable, you may ask, “What is each TRA, and what do entities commonly implement?” Performing a TRA is not always recommended.
| Requirement | What is the TRA? | Common Implementation |
| 5.2.3.1 | Define a frequency for assessing risk to system components from malware. | Review the types of system components the entity has decided are not commonly affected by malware, including network devices. Review threat information to determine how quickly threats to those component types are evolving. If threats are evolving quickly, the organization may want to conduct analyses more frequently. |
| 5.3.2.1 | Define the frequency of malware scans. | The best anti-malware software can continuously analyze system or process behavior. For entities utilizing such solutions, this TRA can be marked ‘Not Applicable’. For all other organizations conducting periodic and real-time scans, review the types of malware threats that these components face. A higher likelihood of malware infection or a higher impact of an infection should result in more frequent scans. Periodic scans are still required even if real-time scanning is in use. |
| 7.2.5.1 | Define the frequency of periodic access reviews of system and application accounts. | Consider how often the access privileges for system and application accounts are likely to change and how much impact accounts would have if compromised. More frequent changes and larger impact should result in more frequent reviews. |
| 8.6.3 | Define the password change frequency. | Review the types of threats the entity’s application and system accounts face. This TRA is directly affected by the complexity of application and system account passwords and the encryption mechanisms used to protect them. Longer, more complex passwords and stronger encryption that is more resistant to brute-force attacks justify less frequent password changes. The number of people with access to the password is also a factor, as more individuals with access increase the chances of a compromise and would require more frequent changes. |
| 9.5.1.2.1 | Define the frequency of inspecting POS/POI devices. | Consider requiring daily inspections, and more frequent inspections for locations with likely or prior incidents. Inspect POI devices not under close employee supervision (e.g., unattended kiosks or fuel pumps) more frequently than supervised POI devices. The number of transactions going through a POI device is also a factor, as a compromised high-volume POI device will result in more stolen data. |
| 10.4.2.1 | Define the frequency of log reviews. | Many companies continuously monitor all alerts, which can eliminate the need for a TRA to determine how often logs need to be reviewed. If you conduct periodic log reviews, consider the risk to account data posed by components that qualify for less frequent log reviews. Higher-risk components warrant more frequent log reviews. |
| 11.3.1.1 | Define remediation timelines for vulnerabilities other than those ranked as critical or high. | Review the likelihood of each vulnerability being exploited and the potential impact that would result from it. Schedule vulnerabilities with higher likelihood and/or impact for faster remediation. Please do not attempt to justify a remediation SLA of more than one year, or demonstrating compliance could become a challenge. |
| 11.6.1 | Define the frequency for reviewing payment pages for unwanted changes and tampering. | Many will not perform the TRA. If the security control is performed at least once a week, then a TRA is not needed. Many organizations use third-party solutions to sample all production sessions or to continuously test every several minutes. A TRA is only required if the organization wants to perform this control less frequently than once per week. Consider the threats facing the payment page and the impact if the page were tampered with. Pages with higher transaction volume have a higher impact and should be checked for tampering more frequently. Complex sites may be more susceptible to tampering and should also be checked more frequently. |
| 12.3.2 | Approve all TRAs and reevaluate annually. | Use the Sample Targeted Risk Analysis Template for the customized approach published by PCI DSS for each control that uses the customized approach. Each customized approach control will need its own unique risk analysis. |
| 12.10.4.1 | Define the frequency of training for Incident Response personnel. | Consider the types of incidents the organization is facing and how quickly they evolve. Rapidly changing threats warrant more frequent Incident Response training so that personnel can be prepared to deal with emerging threats. It is recommended that training occur at least once a year, or demonstrating compliance could become difficult. |
TRA per SAQ Type
This section is ‘expert level’ for those who understand the equivalent SAQ types of their payment channels and operations that can impact cardholder data. If that isn’t you, thanks for reading this far!
SAQ Types for Scope Reduction
PCI Merchants (but not PCI service providers) can declare an ROC or SAQ D requirement as ‘Not Applicable’ using SAQ eligibility criteria. PCI SSC FAQ 1331 acknowledged this approach to reporting scope reduction, and a 2023 PCI Community Meeting further clarified it. This is great news for many merchants.
Service providers, too, will find valid reasons for much of the scope reduction applicable to merchants, but each requirement will need to be demonstrated and reported to indicate why it should be ‘Not Applicable.’ Citing the equivalent SAQ type is not a valid reason to reduce a service provider’s scope.
The TRA requirements are listed again, but this time by the SAQ reports that contain them. These TRA requirements are not contained in any reports not listed below and are therefore out of scope. As implied above, some knowledge is needed to properly scope a TRA, as it is not applicable to your scope.
| Requirement | Scoping per SAQ type |
| 5.2.3.1 | A-EP, C, D |
| 5.3.2.1 | A-EP, C, D |
| 7.2.5.1 | D |
| 8.6.3 | A-EP, C, D |
| 9.5.1.2.1 | D |
| 10.4.2.1 | A-EP, C, D |
| 11.3.1.1 | D |
| 11.6.1 | A, A-EP, D |
| 12.3.2 | D |
| 12.10.4.1 | D |
Defining the TRA Process
The PCI DSS requires that TRAs be performed according to a TRA process that each entity defines for itself but minimally including the elements from Requirement 12.3.1:
“Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.”
Care should be taken to identify threats unique to the business processes. For card-present POI/POS devices, this could include the likelihood of tampering via POS skimmers. Nuanced risk analysis could include, for example, the higher likelihood of skimmers on gas pumps compared to the lower likelihood for POS devices inside a store staffed continuously by personnel. The risk analysis must include the loss-event impact of the various threat scenarios and base frequency on the likelihood/impact of a loss event. Industry threat data is available, or entities can use historic loss data to analyze risk. Entities should resist the temptation to work backward from the frequency they want, merely justifying that conclusion with unsourced data.
Many entities will either copy the PCI DSS nearly verbatim into a new documented process or map these six (6) elements into their existing and mature risk evaluation process. In either case, TRAs will need documented reviews every year.
The PCI SSC has published a TRA template and guidance at https://www.pcisecuritystandards.org:
- Sample Template: TRA for Activity Frequency
- PCI DSS v4.x: Targeted Risk Analysis Guidance
Discover more from Chad M. Barr
Subscribe to get the latest posts sent to your email.
