Rumah » Targeted Risk Analysis in PCI DSS v4.0: What You Need to Know

Targeted Risk Analysis in PCI DSS v4.0: What You Need to Know

Apr 16, 2024 | Article


The Payment Card Industry Data Security Standard (PCI DSS) is a global standard that provides a baseline of technical and operational requirements designated to protect payment data. Any entity that stores, processes or transmits payment card information must comply with these requirements.

What is PCI DSS v4.0?

PCI DSS v4.0 is the next evolution of the standard. As cybercriminals look to exploit our increasing reliance on digital technology to streamline and simplify most aspects of our lives, PCI DSS version 4.0 provides a more robust way for organisations to counteract the techniques used by those seeking to compromise data security defences.

Its primary goal is to enable entities to make informed, risk-based decisions about the frequency and methodology of their security controls, thereby allowing them to enhance the effectiveness of their data security measures. Rather than a one-size-fits-all approach, PCI DSS v4.0 empowers organisations to assess and address the risks most relevant to their operating environment.

PCI DSS v4.0 requires businesses to complete one or more targeted risk analyses (TRAs) that replace the traditional, organisation-wide risk assessments mandated by version 3.2.1. There are two types of TRAs, giving organisations the flexibility to evaluate their risk and determine the security impact of specific requirement controls within their business.

TRAs for periodic requirements

The first type of targeted risk analysis (TRA) focuses on the PCI DSS requirements that give an organisation flexibility about how frequently to perform a given control based on their assessment of risk. These “periodic”

activities generally require a TRA to be completed to determine the most appropriate frequency. The nine requirements that need a TRA completed are:

1. Evaluation of system components not at risk for malware

2. Malware scans

3. Review of access by application and system accounts

4. Periodic password/passphrase changes

5. Physical device inspections for evidence of tampering or substitution

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

7. Addressing vulnerabilities not ranked as high-risk or critical

8. Change and tamper-detection mechanism for web servers

9. Training for incident response personnel

The elements that must be included in a TRA include:

  • 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 realised
  • Resulting analysis that determines and includes justification for how frequently the requirement must be performed to minimise the likelihood of the threat being realised

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