How to Conduct a PCI DSS Risk Assessment

A PCI DSS risk assessment under v4.0.1 is usually a targeted risk analysis tied to a specific PCI DSS control decision. It is not a generic yearly risk register exercise. The analysis should identify the assets being protected, the threats that matter, the factors that affect likelihood or impact, and the reason a chosen control frequency or customized control is appropriate.

PCI DSS uses two types of targeted risk analysis. Requirement 12.3.1 applies when a PCI DSS requirement explicitly lets the organization determine how often an activity should happen. Requirement 12.3.2 applies when an entity uses the Customized Approach for a requirement. The two analyses solve different problems, so they should not be treated as one reusable form.

A targeted risk analysis also has limits. It cannot be used to ignore a minimum frequency that PCI DSS already fixes. If a requirement says an activity must happen at least once every three months, a risk analysis cannot turn that into once a year.

PCI DSS risk assessment at a glance

The term can mean several things in normal security work. In PCI DSS v4.0.1, the important distinction is whether the analysis supports a specific frequency decision or a customized approach control.

What does "risk assessment" mean in PCI DSS v4.0.1?

PCI SSC defines a targeted risk analysis as a risk analysis focused on a specific PCI DSS requirement because the requirement allows flexibility or because the entity is using the Customized Approach. The Council's PCI DSS v4.x Targeted Risk Analysis Guidance explains both types and provides sample templates.

This is different from the older PCI DSS v3.2.1 model, which included a broad annual risk assessment in Requirement 12.2. PCI DSS v4.x puts more emphasis on targeted analyses that answer a defined control question. An organization can still run a wider enterprise or cybersecurity risk assessment, but that broader document does not automatically satisfy a targeted-risk-analysis requirement.

For the standard-level view of scope, validation, and the full control structure, see our PCI DSS requirements guide. It explains where Requirement 12 sits among the 12 requirement groups without turning this page into another general PCI DSS overview.

When is a PCI DSS targeted risk analysis required?

A TRA is required only where PCI DSS makes it part of the requirement. That matters because "risk based" does not mean every control frequency is negotiable.

• Entity-defined frequency. Requirement 12.3.1 applies when a PCI DSS requirement allows flexibility about how frequently an activity is performed and specifically requires a TRA to set that frequency or process.
• Customized Approach. Requirement 12.3.2 applies to each PCI DSS requirement an entity meets with the Customized Approach. This does not apply to entities completing a self-assessment questionnaire.
• Fixed minimum frequency. Where PCI DSS already says "at least once every three months," "every six months," or another fixed interval, a TRA does not reduce that minimum unless the requirement itself provides that flexibility.

Requirement 10 gives a useful example. Some in-scope logs require daily review. Other in-scope logs can be reviewed periodically, and Requirement 10.4.2.1 uses a 12.3.1 targeted risk analysis to set that periodic review frequency.

Our PCI DSS Requirement 10 guide covers that logging decision in context, including which logs require daily review and where a risk-based frequency is allowed.

What must a Requirement 12.3.1 targeted risk analysis contain?

The analysis can be short if the control decision is simple, but it still needs the required ingredients. A vague statement such as "low risk, review quarterly" is not enough on its own.

• Assets being protected. Name the systems, data, services, or other assets connected to the requirement. The analysis should be specific enough that another person can tell what was actually considered.
• Relevant threats. Identify the threat or threats the control is meant to reduce. Keep this tied to the requirement rather than listing every security threat the company has.
• Likelihood and impact factors. Document the conditions that make the threat more or less likely, and the consequences if it occurs. Exposure, privilege, data sensitivity, change rate, user access, dependencies, and past incidents can all matter.
• The resulting control decision. State the frequency or process chosen and explain why it is enough to reduce the likelihood or impact of the threat in that environment.
• Annual review. Review each TRA at least once every 12 months to confirm the result is still valid.
• Updates when needed. If the review shows that the assumptions no longer hold, update the analysis and the control decision.

How do you conduct a PCI DSS risk assessment step by step?

Start with the control decision, not with a blank risk matrix. The purpose is to explain a specific PCI DSS choice in a way the control owner and assessor can follow later.

1. Define the exact decision. Write down the PCI DSS requirement, the activity being assessed, and the decision the TRA needs to support. If the question is "how often should we review these logs?", say that directly.
2. Confirm the affected scope. Identify the CDE systems, connected systems, services, or other components that the decision covers. A TRA built on the wrong scope will give a neat answer to the wrong problem.
3. Name the assets and threats. Keep the threat statement close to the control. For log review, that may be delayed detection of unauthorized access. For a key-management activity, the threat will be different.
4. Evaluate the factors that change risk. Look at exposure, privilege, volume, change rate, business impact, available preventive controls, previous findings, and how quickly an issue could become serious.
5. Choose the frequency or process. Pick the control interval or process that fits the evidence. Do not start with the frequency the team would prefer and work backward to justify it.
6. Document the reasoning and owner. Record the facts used, the decision, who approved it, what evidence supports it, and who is responsible for carrying out the control.
7. Review the analysis and the operating evidence. At least once every 12 months, check whether the analysis still holds. Also check whether the team actually performed the activity at the frequency the TRA selected.

The scope step is where many PCI risk documents become too abstract. Our CDE and PCI DSS scope guide explains how the cardholder data environment, connected-to systems, security-impacting components, and segmentation affect the assessment boundary.

What does a PCI DSS risk assessment example look like?

A small example is more useful than a generic five-by-five heat map. The numbers below are illustrative, not a PCI SSC-prescribed frequency.

PCI SSC FAQ 1304 uses examples such as print servers, stock-control systems, inventory systems, and certain workstations to explain that some in-scope systems may fall outside the daily-log-review categories. The FAQ does not prescribe one review frequency for those systems; the entity's TRA does that.

How is a targeted risk analysis different from a general risk assessment?

The two can share the same risk vocabulary, but they are not interchangeable. A general risk assessment helps a company decide what matters across the business. A PCI DSS TRA explains a narrower control choice.

What can a targeted risk analysis change, and what can't it change?

The safe rule is simple: use a TRA only for the flexibility PCI DSS actually gives you. It is not a waiver process.

• It can define an allowed periodic frequency. For example, Requirement 10.4.2.1 uses a TRA for periodic review of other in-scope logs.
• It can support a Customized Approach control. The analysis helps explain the risk and why the customized control meets the requirement objective.
• It cannot erase a fixed minimum. A requirement with an explicit minimum frequency still has to meet that minimum.
• It cannot make missed evidence reappear. If a required quarterly activity was skipped, a later risk analysis cannot backdate the missing control performance.

Free guide

Keep risk analysis separate from mandatory testing work

A targeted risk analysis does not replace Requirement 11.4 pentesting. Use the playbook to define testing scope, engagement preparation, and the records needed for assessment.

Get the PCI DSS Penetration Testing Playbook

What evidence should be ready for the PCI DSS assessment?

The assessor needs to see more than the final frequency. The point is to show how the organization reached the decision and whether the control operated that way afterward.

• The completed TRA. Keep the requirement reference, assets, threats, risk factors, decision, justification, owner, and review date together.
• The source evidence. Configuration details, asset records, access information, previous findings, incident history, or other facts used in the analysis should be available if they materially support the decision.
• Approval and ownership. The document should show who owns the control and who accepted the resulting frequency or process.
• Operating records. If the TRA says a control is performed monthly, the organization still needs evidence that the monthly activity happened.
• Review history. Keep the annual review and any updated analysis so the assessor can see that the decision was not left untouched after the environment changed.

For the wider validation process, including SAQs, ROCs, AOCs, remediation, and evidence review, see our PCI DSS audit and assessment guide. A TRA is one piece of assessment evidence, not the assessment itself.

How does PCI DSS risk assessment connect to vulnerability management?

Risk analysis can help a team prioritize remediation and explain decisions, but it does not replace the scanning and remediation duties in Requirement 11. Fixed scan frequencies still apply where PCI DSS sets them.

Our PCI DSS vulnerability scanning and vulnerability management guide explains internal scans, ASV scans, rescanning, remediation, and the evidence that has to survive the assessment.

This boundary is useful in practice. A risk register may say a vulnerability is low priority for the business, while PCI DSS still requires a defined scanning or remediation action. The compliance decision has to respect the standard first, then use risk information inside the flexibility that remains.

Common PCI DSS risk-assessment mistakes

Most weak TRAs fail because the reasoning is too generic or because the team treats the document as permission to choose an easier control schedule.

• Reusing an enterprise risk register without narrowing it to the PCI control. The document may be useful background, but it often does not answer the specific frequency or customized-control question.
• Choosing the answer before doing the analysis. A preferred monthly or quarterly schedule should not appear first and then receive a convenient justification afterward.
• Using a TRA where the standard sets a fixed minimum. Risk analysis cannot reduce an explicit PCI DSS minimum frequency.
• Ignoring scope changes. New services, network paths, third parties, cloud components, or administrative access can make the original assumptions stale.
• Keeping no evidence of the control after the TRA. The analysis explains what should happen. Assessment evidence still has to show that it did happen.
• Letting one person own the document but nobody own the control. The TRA is easier to defend when the operating owner, compliance owner, and evidence source are clear.

Final thoughts: A useful PCI DSS risk assessment ends with an operating decision

The value of a targeted risk analysis is not the score or the template. It is the documented connection between a PCI DSS requirement, the actual environment, a security risk, and a control decision that someone can operate and later prove.

Keep the document specific. Keep the assumptions visible. If the environment changes, revisit them. That makes the TRA much easier to use during the year and much less painful when assessment evidence is requested.

Frequently asked questions about PCI DSS risk assessment

Is a PCI DSS risk assessment required every year?

Each Requirement 12.3.1 targeted risk analysis must be reviewed at least once every 12 months. That is a review of the targeted analysis, not a return to the old v3.2.1 requirement for one broad annual PCI risk assessment.

Does every PCI DSS requirement need a targeted risk analysis?

No. A TRA is required where the standard specifically calls for one, or when an entity uses the Customized Approach for a requirement.

Can a PCI DSS risk assessment reduce quarterly vulnerability scanning?

No. A TRA cannot reduce an explicit minimum frequency. Where PCI DSS requires scanning at least once every three months, that minimum still applies.

What is the difference between a PCI DSS risk assessment and a PCI DSS assessment?

A risk analysis supports a specific control decision. A PCI DSS assessment evaluates compliance across the applicable standard and produces the required validation records, such as an SAQ or ROC and AOC.

Can we use our ISO 27001 or NIST risk method for PCI DSS?

You can use an existing method as a foundation, but the PCI DSS TRA still needs to contain the specific elements required by 12.3.1 or the Customized Approach.

Who should own the targeted risk analysis?

PCI DSS does not require one job title. In practice, the control owner should contribute the technical facts, while security, risk, or compliance makes sure the required reasoning and evidence are documented.

Does a targeted risk analysis need a numeric risk score?

PCI DSS requires the risk factors and resulting analysis, not one mandatory scoring scale. Use a method that makes the reasoning clear and repeatable.

What happens if the environment changes after the TRA is approved?

Recheck the assumptions. The standard requires annual review and updates when needed. A material scope or threat change is a sensible reason to review the analysis sooner.