ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A PCI DSS targeted risk analysis is a focused, documented assessment of the risk tied to one specific requirement, and it is the mechanism PCI DSS version 4.0 uses to give organizations flexibility. It appears in two places: requirement 12.3.1, which lets you set the frequency of certain activities based on your own risk, and requirement 12.3.2, which requires a targeted risk analysis for each requirement met through the customized approach. Both became mandatory on 31 March 2025, after the future-dated period ended, so assessors now expect to see them.
This guide explains what the two requirements ask, what a good analysis contains, how to keep it current and how it fits with the rest of your compliance programme. It builds on our guides to PCI DSS scope, PCI DSS documentation and PCI DSS versus ISO 27001. Check the requirement text in the version you are assessed against.
Free gap assessment
How much of PCI DSS v4 is actually in place?
Score all twelve requirements at sub-requirement level, free, including the ones that stopped being future-dated in 2025.
Run the free PCI DSS 4.0 gap assessment → or View premium report sample
Two requirements use targeted risk analysis, as summarised by a German security consultancy that specialises in payment standards.
| Requirement | Purpose | What you decide |
|---|---|---|
| 12.3.1 | Determine how often to perform activities in requirements that allow flexible frequency | The frequency, justified by risk |
| 12.3.2 | Support requirements met through the customized approach | Whether your alternative controls meet the objective |
The analysis is targeted because it concentrates on a single requirement, not on enterprise-wide risk. That makes each analysis small and specific, but you may need several.
Some PCI DSS requirements say an activity must be performed “periodically”, or at a frequency the entity defines, instead of prescribing an interval. Examples include certain reviews and checks of system components. For those, you must perform a targeted risk analysis to determine how often to do the activity. The summary says the guidance suggests looking at threat levels and potential damage, using industry references such as NIST or BSI, and then documenting the chosen frequency.
Look in the standard to find which requirements carry this flexibility. The requirement list can change between versions, so use your current copy, and build a register of every flexible-frequency requirement in scope with its analysis.
The standard describes the content of a targeted risk analysis. In summary, it should include the following elements. Verify the wording in the text.
The requirement also expects documented approval of the results by senior management. Assign a named approver, and keep the sign-off with the analysis.
The customized approach lets an entity meet a requirement’s stated objective in a way that differs from the defined approach, for example with a different technology. Requirement 12.3.2 says a targeted risk analysis must be performed for each requirement implemented this way. It has to show that the alternative control meets the objective and that the residual risk is acceptable. The standard provides a template in an appendix, according to the summary.
The customized approach demands more effort, including additional documentation and testing by an assessor, so use it sparingly and where it delivers real value. Our guide to PCI DSS self-assessment questionnaires explains that some validation routes may not allow the customized approach, so check eligibility first.
Keep each analysis to a page or two. Writers often produce long, generic essays. Assessors prefer specific reasoning tied to the environment: how many systems, how exposed, what changes and what history of issues.
A targeted risk analysis is not a one-off. Review each at least every 12 months, and sooner when something changes, such as a new system, a major incident or a change in threat information. Track the analyses in a register with owners, dates and links to the evidence. Include the review in your annual compliance calendar so that no analysis lapses before the assessment.
If a frequency turns out too low, for example because incidents show weaknesses, adjust it and record the change. Our guide to PCI DSS compliance cost discusses budgeting for the extra analysis and testing.
A PCI DSS targeted risk analysis works best when it connects to the risk process the company already runs. Use the same likelihood and impact scales as the enterprise risk register, so that leaders see one consistent view. Link each analysis to the relevant register entry, and feed findings from incidents, penetration tests and vulnerability scans into the threat and likelihood sections. If your organization also follows ISO 27001, the two efforts can share methodology, although the PCI analysis remains specific to each requirement. This avoids duplicate work and gives assessors a coherent story.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Assign an owner to each analysis, typically the person who runs the control day to day, and an independent reviewer from security or compliance who challenges the reasoning. Senior management approves the result. Give the compliance lead a register of all analyses, with due dates for review, and report status to the security steering group each quarter. Where external providers perform the activity, such as a managed security service, the provider’s frequency is part of the analysis, and the contract should support it.
Before you commit to the customized approach, weigh costs and benefits. It can allow modern technology to meet an objective that the defined requirement did not anticipate, but it needs a robust analysis, extra documentation and assessor testing that goes beyond the standard procedures. Ask whether the defined approach with a compensating explanation would be simpler, and whether the assessor has experience with the customized approach. Record the decision, the reasoning and who approved it, so the next assessment starts with the history.
Plan the first round of analyses well before an assessment. List all in-scope flexible-frequency requirements, prioritise by risk, and write the high-risk analyses first. Set aside time each quarter for reviews so that the annual cycle does not become a last-minute rush. Small teams may write most analyses in a few workshops, using a standard template and adapting each result to the environment.
A hypothetical online retailer must decide how often to review a set of system component logs for which the standard leaves the frequency to the entity. The security lead writes a targeted risk analysis: the assets are the web servers and payment page scripts, the threats include skimming and unauthorised changes, and the likelihood factors include internet exposure and frequent releases. The analysis sets daily automated review with weekly manual sampling, and states why less frequent checks would be too slow to catch a script change. The chief technology officer approves it, and the analysis is scheduled for review in twelve months. The example is invented for illustration.
The summary of the requirements used here comes from the usd article on targeted risk analysis in PCI DSS. Always confirm the wording in the standard published by the PCI Security Standards Council and ask your assessor.
To avoid building analysis templates, registers and review calendars from scratch, the PCI DSS Toolkit provides documents you can adapt. Have your qualified assessor confirm they meet your validation route.
For requirements that let you define the frequency of an activity (12.3.1), and for each requirement met with the customized approach (12.3.2).
These requirements were future-dated until 31 March 2025, so assessors now expect them.
At least every 12 months, and when changes affect the analysis.
Senior management, according to the requirement summary. Keep a record of approval.
Yes, but tailor it to your environment. Generic text does not show real analysis.
September 30, 2026
