WithPCI Logo
WithPCI.com

12.3.1 For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes:

Original requirement from PCI DSS v4.0.1

Defined Approach Requirements

12.3.1 For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis 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 the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact 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.

Customized Approach Objective

Up to date knowledge and assessment of risks to the CDE are maintained.

Applicability Notes

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Defined Approach Testing Procedures

12.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that specifies completion of a targeted risk analysis, and that the process includes all elements specified in this requirement.

Purpose

Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to the entity's environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.

This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.

The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.

Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.

Good Practice

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).

Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.

Definitions

A targeted risk analysis is a formal, documented analysis of a PCI DSS requirement that an entity is allowed to define the frequency with which it is performed.

Further Information

Refer to the following documents on the PCI SSC website:

  • Information Supplement: TRA Guidance
  • Sample Template: TRA for Activity Frequency.

purpose

Define and implement usage policies for critical technologies.

compliance strategies

  • Acceptable use policies
  • Technology-specific controls

typical policies

  • Technology Usage Policy

common pitfalls

  • No policy for new tech
  • Unclear restrictions

type

Documentation/Process Control

difficulty

Low

key risks

  • Inappropriate technology use

recommendations

  • Review policies with IT and business units

Eligible SAQ

  • SAQ-A-EP
  • SAQ-C
  • SAQ-D MERCHANT
  • SAQ-D SERVICE PROVIDER

Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy