Can I simply convert old risk values to the new scale?

Only if a defensible mapping is actually possible. Different criteria and thresholds cannot be made comparable merely by applying a conversion factor.

Must I reassess every risk immediately?

Plan the transition according to relevance and applicable requirements. Clearly identify the method version in the meantime, and do not combine old and new values into an apparently uniform ranking.

Changing your risk method: How do assessments remain comparable?

A new risk matrix can make sense if existing categories are too broad or impact definitions do not fit the business. The change becomes dangerous when lower numbers are subsequently presented as better security.

Preserve the previous assessment state and identify the method behind each result. A new scale changes the measurement first, rather than automatically changing the risk.

What actually changes?

Before the transition, write down the problem you want to solve. Does only a label change, or does the assessment’s meaning change too?

Change	Possible consequence
Different number of levels	Old values do not map unambiguously to new categories
Different impact thresholds	The same scenario receives a different impact level
Different time horizon	Likelihood refers to a different period
New acceptance criteria	Earlier decisions need review
Different losses considered	Additional aspects change the overall result

A risk matrix is only part of the method. Assumptions, scenarios and decision rules are equally important.

NIST SP 800-30 distinguishes the risk model from the assessment approach and emphasises traceable, repeatable assessments. For a method change, preserve the result and how it was reached. NIST SP 800-30, chapters 2 and 3

Preserve an explainable baseline

Before switching, record the applicable method version, assessment date, assumptions, result and existing decisions. Link the evidence used. An exported number without this context cannot explain later differences.

If new information arrives at the same time, separate the two changes: what result would the new method produce with the facts unchanged? What additional change comes from the new facts?

Our risk review guide explains reassessment when circumstances change. A method change is a separate trigger and should be identifiable as such.

Assess some cases in parallel

Deliberately select different scenarios: a clearly minor case, a case at the acceptance boundary and a significant risk. Assess identical assumptions using both methods.

Fictional case: An organisation replaces a three-level impact scale with five levels. An outage previously rated medium now falls into the second level. That is not demonstrated risk reduction. Comparing the underlying outage consequences reveals whether the classification has simply become more granular.

Also check whether different assessors reach similar results using the same information. Large differences can indicate unclear definitions. Resolve them before migrating the whole register.

Decide how to transition

Set a cutoff date and decide which assessments move first. Review whether existing risk acceptances still have a valid basis. A new colour must neither silently replace an earlier approval nor carry forward an obsolete decision.

For each migrated case, document the old method, new method, new finding and reason for the difference. Explicitly mark any break where meaningful conversion is impossible.

Transition record

Use these fields for each comparison case. Reassess cases that cannot be compared instead of forcing a mapping rule.

Review field	Entry
Subject and data state	Scenario, assumptions and evidence
Old method	Version, criteria and result
New method	Version, criteria and result
Comparability	Mapping rule or reasoned break
Substantive consequence	Reassessment or unchanged decision with reasoning
Approval	Authorised decision-maker, date and next review trigger

Keep reporting honest

Present time series before and after the transition separately, or explain limited comparability directly in the chart. Do not simply aggregate old and new risk levels.

Tell management what the new method distinguishes better and which decisions follow. ISMS metrics should reveal changed measurement logic instead of producing apparent progress.

In Kopexa, you can work on risks and associated measures. Test a method change first using sanitised comparison cases in your specific configuration. Risk management software should support the subject-matter context; the responsible people still need to justify assessments.