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 being for “particularly personal computers and servers” and is for all system components, including network devices, which must be evaluated for susceptibility for malware.

5.3.2.1

This is applicable for many entities using SAQs A-EP, C, and D if performing real-time and periodic malware scans rather than a continuous behavioral analysis of systems or processes for malware. Endpoint protection is advancing so rapidly that this will shift over time to being applicable to fewer entities.

7.2.5.1

This is applicable for many entities using SAQ D. This requirement applies to all application and system accounts and related access privileges.

8.6.3

This is applicable for most entities using SAQs A-EP, C, and D. This requirement applies to any organization that is using password or passphrase authentication on application or system accounts.

9.5.1.2.1

This is applicable for 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 is applicable for 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 the categories that require daily reviews.

11.3.1.1

This is applicable for 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 is applicable only to entities using the customized approach rather than the defined approach that most organizations use for PCI DSS compliance. This requirement applies to each requirement that uses the customized approach.

12.10.4.1

This is applicable for all entities using SAQ D . This requirement applies to Incident Response training.

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 of anti-malware software can continuously analyze behaviors on systems or processes. 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. Note that periodic scans are 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 impacted by the complexity of the application and system account passwords and the encryption mechanisms used to protect those passwords. Longer and more complex passwords using stronger encryption that is more resistant to brute-force attacks will justify less frequent password changes. The number of people who have access to the password is also a factor, as having more individuals with access increases 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 for locations with likely or prior incidents. POI devices that are not under close employee supervision, e.g., unattended kiosks or fuel pumps, should be inspected more frequently than POI devices that are supervised. 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 are continuously monitoring all alerts, and this can eliminate the need for a TRA to determine how often the logs need to be reviewed. If periodic log reviews are conducted, consider the risk posed to account data by the 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. Vulnerabilities with a higher likelihood and/or impact should be scheduled for more rapid 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 will use third-party solutions to sample all production sessions or at least 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 that would result if the page was tampered with. Pages with a larger transaction volume would have 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 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 the that training occurs no less than once a year, or demonstrating compliance could become difficult.

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