How to complete the Targeted Risk Analysis for PCI DSS V4.0

With the introduction of PCI DSS v4.0, a new concept called Targeted Risk Analysis (TRA) has emerged, bringing with it a more nuanced approach to managing and assessing risks within an in scope environment. This blog post aims to simplify the TRA process and provide you with a clear understanding of how to effectively implement it within your organization.

 

Understanding Targeted Risk Analysis

The intent of PCI DSS v4.0 Requirement 12.3 is to focus on certain targeted risk areas specific to PCI DSS requirements, whereas v3.2.1 required a general risk assessment, which many organizations were meeting with an enterprise-wide risk assessment that may not have had much to do with your payment processes and systems. 

 

The new Targeted Risk Analysis requirement is split into four sub requirements:

1. 12.3.1 - TRA for Activity Frequency Determination: This TRA is performed for PCI DSS requirements that offer flexibility on the frequency of a particular control. It allows organizations to assess the risk to their environment and define an appropriate frequency for these controls.
2. 12.3.2 - TRA for the Customized Approach: This is applicable for entities meeting certain PCI DSS requirements through a customized approach. It involves a detailed risk analysis to ensure the controls meet the objectives and offer equivalent protection as the standard requirements.
3. 12.3.3 - TRA for Cryptographic Ciphers Suites and Protocols: Entities must now keep an inventory of all cipher suites and protocols in use and monitor the continued viability of each. Future dated to 31st of March 2025.
4. 12.3.4 - TRA for Hardware and Software: Entities are now required to monitor all hardware and software to ensure they remain supported by the vendor. Entities must also make plans for any products where end-of-life has been announced. Future dated to 31st of March 2025.

Which requirements need to be cover for 12.3.1?

The following is a list of requirements that entities will need to handle in accordance with the TRA process (assuming they're in scope for your environment). 

PCI DSS v4.0 Requirement	PCI SSC Suggested Frequency
5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.	At least once every six months
5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.	At least once a day
7.2.5.1 All access by application and system accounts and related access privileges are reviewed as follows: • Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). • The application/system access remains appropriate for the function being performed. • Any inappropriate access is addressed. • Management acknowledges that access remains appropriate	At least once every six months
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows: • Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise. • Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.	At least once every three months
9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.	At least once every month
10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1	At least once a week
11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: • Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. • Rescans are conducted as needed.	Medium: within three months Low: Within six months Informational: Monitor regularly
11.6.1 A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. • The mechanism is configured to evaluate the received HTTP header and payment page. • The mechanism functions are performed as follows: – At least once every seven days OR – Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).	At least once every seven days
12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.	At least once a year and at the start of employment

 

Key Questions Answered

• How often do I need to do a TRA? TRAs must be performed / reviewed at least once every 12 months.
• Can an entity perform a TRA to lessen the frequency than what is stated in a PCI DSS requirement? No. If a requirement states that something has to be done monthly, you must perform that action monthly. Frequency of activities can only be determined for those requirements listed above. You can choose to do some activities more often (like your ASV scans, do them monthly!), but that does not have to be covered by your TRA.
• Do I still need to do an enterprise risk assessment? Not for your PCI DSS assessment. 
• Is there a template for TRA? Yes! We provide a template in our ROC / SAQ D / SAQ D-SP template pack and you can even download one for free from our sample template pack.

Conclusion

In my opinion the TRA is a huge step in the right direction, as a QSA I've been handed many risk assessments that had nothing to do with the CDE I was assessing.