PCI DSS v4.0: Targeted Risk Analysis Explained

Article PCI DSS
Targeted Risk Analysis

With version 4.0 of the PCI DSS, the PCI Security Standards Council (“PCI Council”) has significantly changed the approach organizations must take toward risk assessment. Risk assessment under PCI DSS v4.0 takes the form of one or more narrowly focused “targeted risk analyses,” or TRAs, which completely replace the traditional, organization-wide risk assessments required by version 3.2.1. TRAs are designed to guide an organization in making informed risk-based decisions when there is flexibility in how to go about meeting a particular PCI DSS requirement. This falls under one of two categories, each with a corresponding set of specifics in how to conduct the TRA:

Customized Approach

First, a TRA must be completed for each requirement met through the “Customized Approach.” The Customized Approach is intended to permit flexibility in organizations with highly-mature information security and risk management programs. As CampusGuard discussed in a previous article, it requires more effort and cost to implement controls under the Customized Approach than the traditional “Defined Approach.” Additionally, the Customized Approach cannot be used with Self-Assessment Questionnaires, so we anticipate few organizations choosing to use the Customized Approach. Accordingly, the remainder of this article focuses on the other situation in which TRAs are used: alongside periodic requirements.

TRAs for Periodic Requirements

PCI DSS requirements that include an activity that must be completed “periodically” (i.e., no specific frequency is defined within the requirement) generally require completion of a TRA to determine the appropriate frequency to perform the activity. There are nine requirements that include the completing a TRA:

  1. Evaluation of system components not at risk for malware (Requirement 5.2.3.1)
  2. Malware scans (Requirement 5.3.2.1) *
  3. Review of access by application and system accounts (Requirement 7.2.5.1)
  4. Periodic password/passphrase changes (Requirement 8.6.3)
  5. Physical device inspections for evidence of tampering or substitution (Requirement 9.5.1.2.1)
  6. Periodic log reviews for system components that do not store process or transmit Cardholder Data/Sensitive Authentication Data, are not critical system components, and do not perform security functions (Requirement 10.4.2.1)
  7. Addressing vulnerabilities not ranked as high-risk or critical (Requirement 11.3.1.1)
  8. Change- and tamper-detection mechanism for web servers (Requirement 11.6.1) **
  9. Training for incident response personnel (Requirement 12.10.4.1)

While the PCI Council has yet to publish a template TRA form for use with periodic requirements (a sample template for use with the Customized Approach is published in Appendix E2 of the PCI DSS v4.0), Requirement 12.3.1 does give us a list of the essential elements that must be included in a TRA:

  • 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

Additionally, each TRA must be reviewed at least annually, and an updated analysis performed if determined by the annual review.

Impact to Organizations Transitioning to 4.0

While traditional, organization-wide risk assessments are no longer required under v4.0 of the PCI DSS, it is still considered good practice to conduct them, and they may be required under other information security regulations or standards as well. Furthermore, in its guidance under Requirement 12.3.1, the PCI Council still recommends that organizations continue to carry out traditional risk assessments even where not required:

An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization’s overall information security policy (see Requirement 12.1.1).

If all this sounds daunting, there is no need to panic. TRAs are new requirements under v4.0 of the PCI DSS, and the PCI Council has given organizations an additional year after the deadline for transitioning to v4.0 to implement these controls. Accordingly, TRAs are not mandatory until after March 31st, 2025; in the meantime, they are only considered best practice.

Finally, in practice, your organization may not be required to conduct any TRAs, due to possible scope reduction and/or limiting your assessment to particular SAQs. And as we approach the transition date for v4.0 and implementation date for TRAs, we expect further guidance and clarifications from the PCI Council. CampusGuard will continue to monitor for such updates, and your CampusGuard team can work with you to help determine applicability of TRA requirements and how to meet them as you work towards preparing for your transition to v4.0 of the PCI DSS.

*TRA only required where not using continuous behavioral analysis tools for malware detection

**TRA only required if evaluation and alerting occur less frequently than once every seven days

Share

About the Author
David Gundrum Headshot

David Gundrum

JD, CISA, CISSP, QSA

Security Advisor

As a Security Advisor and Payment Card Industry (PCI) Qualified Security Assessor with CampusGuard, David helps customers understand compliance implications and information security risks associated with their environments and identify a path forward toward a secure and compliant state. He brings to CampusGuard experience gained from a diverse range of prior information technology and information security roles, with expertise in risk and compliance assessment, policy and procedure development, vulnerability management, vendor management, and various operational and hands-on technical responsibilities. He holds several industry certifications in information security and privacy, a bachelor’s degree in Computer Engineering from Northwestern University, and a Juris Doctor from The University of Arizona, where his studies focused on issues at the intersection of law and technology.