Targeted risk analysis

How targeted risk analysis works

Targeted risk analysis is not a one-time narrative about “why we think this is acceptable.” It is a documented method for justifying a control’s frequency or implementation choices under a customised compliance approach, with enough structure that the rationale can be tested again later and reproduced by another reviewer.

The key idea is repeatability. A valid analysis should explain the conditions that shaped the decision, the evidence used, and the assumptions that would cause the answer to change. Without that, the document becomes a snapshot of a past judgement rather than an operational control decision.

In practice, this makes targeted risk analysis a bridge between baseline requirements and controlled exceptions. It lets an organisation show that a tailored control choice was not arbitrary, while still keeping the justification tied to a real risk model rather than a permanently frozen policy note.

Where targeted risk analysis fits in a customised compliance model

Targeted risk analysis is most useful when a framework allows a customised or alternative approach, but still expects the organisation to justify the decision. The analysis then becomes part of the compliance evidence, not a replacement for the requirement itself.

That means the control owner needs to connect the choice back to scope, assets, exposure, and operating context. A good analysis explains why the control runs at a particular cadence, why that cadence is sufficient for the current environment, and what would invalidate the judgement if the environment changes.

Because the analysis is targeted, it should stay narrow. It should address the specific control, the specific condition being justified, and the specific environment in which the judgement applies. Broad risk language is not enough if it cannot support a concrete control decision.

The strongest versions are measurable. They describe observable triggers, review points, and decision criteria so the logic can be checked again during audit, internal review, or control operation.

Why the quality of the justification matters

A targeted risk analysis loses value when it is written once and never revisited. That creates a stale justification problem: the control may stay in place, but the operating assumptions behind it may no longer be true.

This matters because customised controls often depend on business context, technology state, or threat conditions that can shift over time. If the analysis is not kept current, an organisation may continue to rely on a justification that no longer matches its actual exposure.

Well-formed analysis also reduces ambiguity between “we decided this once” and “we can still defend this now.” That distinction is important in audits, governance reviews, and change-heavy environments where control frequency, evidence collection, or operating mode may evolve.

What practitioners should look for in the analysis

A useful targeted risk analysis should make the control decision traceable. It should identify the risk being addressed, the basis for the chosen frequency or implementation, and the conditions under which the decision must be reassessed.

It should also be specific enough that another reviewer can test the logic against the same facts. If the reasoning cannot be checked, repeated, or updated after an environment change, the analysis is too fragile to serve as durable compliance evidence.

For PCI-oriented programmes, practitioners often pair the justification with broader control documentation so the decision sits inside a defensible compliance record. NHIMG’s PCI DSS 4.0 Guide, PCI DSS Customised Approach and Targeted Risk Analysis Guide, and PCI DSS Readiness Checklist each support different parts of that workflow: the requirement context, the analysis itself, and the evidence needed to keep the rationale current.

Risk and Threat Considerations

Targeted risk analysis can fail when organisations treat it as a permanent exemption rather than a living justification. The result is control drift, where the documented rationale no longer matches the actual threat or operating condition.

Failure mechanism: The justification is written against one set of assumptions, but the environment changes and no one re-tests whether the control frequency or implementation is still defensible. That can leave an audit trail that appears orderly while the underlying control is no longer proportionate to the real risk.

Impact: The organisation may keep a weak or outdated control posture, miss the point at which the risk profile changed, or fail to defend the decision during review. In the worst case, the analysis becomes evidence of process formality rather than evidence of risk-based control design.

Practitioner Guidance

Why practitioners should care: A targeted risk analysis should be written so it survives review, not just approval. If the rationale depends on context that can change, the document must make those dependencies explicit so the control can be re-tested later.

Common misunderstanding: A customised approach is not the same as an open-ended waiver. The analysis still needs a testable basis for the chosen control behaviour, and that basis should be strong enough to explain why the decision remains valid when conditions shift.

Practitioner takeaway: Treat the analysis as a reusable decision record, not a static memo, and reassess it whenever the control environment or risk assumption materially changes.

Related resources from NHI Mgmt Group

• Why does PCI DSS 4.0 place more emphasis on targeted risk analysis and continuous compliance?
• What is the difference between periodic scope validation and targeted risk analysis in PCI DSS 4.0?
• Why does codifying targeted risk analysis improve PCI compliance?
• Why does performance trace analysis create new access risk for AI tools?