PCI DSS targeted risk analysis: how do you set your own frequencies?

If your organization takes card payments, PCI DSS v4.0.1 lets you set your own schedule for nine recurring security tasks, from log reviews to card terminal inspections. The condition is a written PCI DSS targeted risk analysis behind each schedule. Requirement 12.3.1 has been mandatory since March 31, 2025, so an assessor or your acquiring bank can ask to see that document, and "we've always done it monthly" is not a justification the standard accepts.

What is a PCI DSS targeted risk analysis?

A targeted risk analysis (TRA) is a short written analysis that justifies how often your organization performs a specific PCI DSS control. It replaces the broad annual risk assessment that version 3.2.1 required under Requirement 12.2 with narrow analyses tied to individual requirements, as the PCI Security Standards Council explains in its targeted risk analysis guidance, published in November 2023.

PCI DSS v4.x uses TRAs in two ways. An activity frequency TRA, under Requirement 12.3.1, supports a requirement that lets you decide how often to do something. A customized approach TRA, under Requirement 12.3.2, supports a control you designed yourself to meet a requirement's objective. Most small and midsize merchants only need the first kind, and that is the focus here.

Which PCI DSS requirements let you set your own frequency?

Nine requirements in PCI DSS v4.x let you choose how often to perform an activity, provided a TRA supports the choice. The Council's guidance lists them:

• 5.2.3.1: periodic evaluation of system components you have judged not at risk for malware.
• 5.3.2.1: periodic malware scans, where you rely on scheduled scans rather than continuous behavioral analysis.
• 7.2.5.1: review of access held by application and system accounts.
• 8.6.3: password changes for application and system accounts.
• 9.5.1.2.1: inspections of card terminals and other point-of-interaction devices for tampering or substitution.
• 10.4.2.1: log reviews for system components not covered by the daily review in 10.4.1.
• 11.3.1.1: addressing vulnerabilities that are not rated high-risk or critical.
• 11.6.1: change and tamper detection on payment pages, if you check less often than the default of once every seven days.
• 12.10.4.1: periodic training for incident response personnel.

Which of these apply depends on how you accept cards and which self-assessment questionnaire (SAQ) or report you validate against. An organization whose online payments are fully outsourced may see few of them. One that runs card terminals at a front desk or hosts its own payment page will see more. Our guide to choosing the right PCI SAQ covers that first decision.

What must a targeted risk analysis include?

Requirement 12.3.1 sets six elements that every activity frequency TRA must document:

• The assets being protected.
• The threat or threats the requirement protects against.
• The factors that contribute to the likelihood or impact of a threat being realized.
• The resulting analysis that determines, and justifies, how often the requirement must be performed to minimize the likelihood of the threat being realized.
• A review of each TRA at least once every 12 months to confirm the results are still valid.
• An updated risk analysis when the annual review shows one is needed.

The requirement became mandatory on March 31, 2025, according to the Council's summary of changes from v3.2.1 to v4.0. The Council also publishes a sample template for activity frequency TRAs in its document library, which is a reasonable format to start from.

Can a TRA set any frequency you want?

No. A TRA sets the frequency only for requirements that offer that choice, and the analysis must show why the chosen frequency is enough to minimize the likelihood of the threat. Where a requirement states a fixed frequency with no TRA option, such as internal vulnerability scans at least once every three months under 11.3.1, a TRA cannot change it. Doing an activity more often than a stated frequency never needs a TRA. If a legitimate technical or business constraint stops you from meeting a stated frequency, the route is a compensating control documented under the standard's appendices, which brings its own analysis.

That matters most for 11.6.1. The requirement allows a weekly check or a frequency set by a TRA, so any schedule slower than weekly needs a strong analysis. If your organization hosts a payment page, weekly is the simpler default. Our article on stopping e-skimming under 6.4.3 and 11.6.1 walks through how those checks work in practice.

What does a good TRA look like in practice?

A good TRA is short, specific to your environment and honest about the trade-off. Take Requirement 9.5.1.2.1 at a firm with two card terminals at a staffed reception desk:

• Assets: two countertop terminals, both in view of staff during business hours and locked away after hours.
• Threat: tampering or skimming overlays that capture card data.
• Likelihood and impact factors: the terminals are never left unattended, they are not outdoors or in a public lobby, and transaction volume is modest. A compromised terminal would still expose every card used until the next inspection.
• Resulting frequency: weekly visual inspection by the office manager using a checklist and photos of each device, plus an immediate inspection after any after-hours access by a vendor.
• Review: the office manager and the person responsible for PCI compliance review the TRA every 12 months, or sooner if a terminal moves or a new location opens.

Compare that with a firm running terminals at an unstaffed kiosk. The same template would justify a more frequent inspection. That is the point of a TRA: the frequency follows the risk, and the document shows the reasoning.

Who should own and sign off on the TRAs?

The person accountable for PCI compliance should own the TRAs, with input from whoever performs each activity. At a law firm that is often the firm administrator. At a nonprofit it may be the finance director. PCI DSS does not name a required approver for 12.3.1, but the assessor will confirm that every element is documented and that the frequency is justified. A TRA written by your IT provider and never read by management tends to fail that test, because nobody inside the organization can explain it.

Keep the TRAs with your other PCI evidence: the SAQ, the scope confirmation required by Requirement 12.5.2 and your service provider records. The acquiring bank or payment processor that asks for your annual SAQ is usually the party that will want to see them.

What should you do this quarter?

Most organizations can finish this work in a few hours once the inventory is right:

• List which of the nine flexible-frequency requirements apply to your SAQ or report.
• For each one, write down what you do today and how often. If you cannot say, that is your first gap.
• Write one TRA per requirement using the six 12.3.1 elements. Keep each to a page.
• Check every chosen frequency against any minimum the requirement sets, especially 11.6.1.
• Put the 12-month review on the calendar, tied to your annual SAQ and the 12.5.2 scope confirmation.
• Store the TRAs where the person who signs your SAQ can find them.

How does s90 help?

s90 offers PCI DSS as a standalone add-on, because card acceptance varies so much between organizations. We help clients confirm scope, draft TRAs that match how their environment works, and keep the evidence behind each frequency, such as scan results, log review records and terminal inspection checklists, in one place for the annual review. If your next SAQ is coming up and the TRAs are not written yet, we are happy to help you get them done.