If you're running Risk Management and considering the move to Advanced Risk, the switch itself is a single system property — but what it does behind that switch is significant and cannot be reversed. This post walks through exactly what changes, what stops working, and the checklist I'd run before flipping it in production.

 

Migration is one-way:

Enabling Advanced Risk is not a reversible toggle. Once it's on, the platform actively blocks turning it back off — attempting it aborts with:

▎ You cannot disable advanced risk assessment after it is activated.

• There is no supported rollback, and some of what migration does (see "in-flight assessments" below) destroys data that turning the property back off would not restore.
• Do this in a sub-production instance first. Clone production, migrate the clone, and let your risk team work in it for a full assessment cycle before you touch production.

Navigate to System Properties → Advanced Risk Assessment. The property you want is:

"Migrate to Advanced Risk Assessments"

That's the only migration switch you need to set. A second property, "Migrate to Advanced Risk Rollup", is set automatically for you the moment you enable the first one — you don't need to find it or touch it. Requires the sn_risk.admin role.

 

Perform these three things BEFORE you migrate:

 

1. Publish a Risk Assessment Methodology (RAM) and set it as primary — for every entity class you use.

After migration, a risk can only be assessed through the primary RAM of its entity's class. If an entity class has no published, primary RAM, every risk under it is pushed to Draft and users get:

▎ You cannot assess the risk as there are no published risk assessment methodologies for the entity related to this risk. Contact your risk administrator for details.

There is no warning and no pre-flight check for this — so users need to verify it themselves.

1. Decide your risk appetite model.

Set "Define risk appetite as" to a 1-point or 2-point scale. If you leave it as None, the entire Risk Appetite and Tolerance feature stays inert and you lose the legacy tolerance actions with nothing replacing them (details below).

1. Close out or accept the loss of in-flight legacy assessments.

Migration cancels every legacy risk assessment currently in Ready or Work in Progress. They are set to Cancelled in bulk. Get them completed, or export what you need, before you migrate.

 

What happens the moment you enable it:

1. The Rollup property switches on automatically.
2. Legacy in-flight assessments are cancelled (Ready and Work in Progress → Cancelled).
3. Risk states are recalculated. Risks with no primary RAM go to Draft; the rest get a state derived from their assessment.
4. The primary RAM is stamped onto your entities, derived from each entity class.
5. Navigation changes — legacy aggregated risk report modules are replaced by the advanced aggregation modules (Aggregation by Entities, Aggregation by Risk Statements, Entity by Risk Statements).
6. The Risk form changes to the Advanced Risk view in both the classic UI and workspace, with new sections: Ownership, Risk appetite, Assessment summary, Activity journal, Monitoring.
7. The Review lifecycle stage is switched off and it managed by the assessment with formal approvals.

On a large dataset, steps 2–4 are bulk operations that trigger the normal business-rule cascade. Plan a maintenance window and don't migrate mid-assessment-cycle.

 

The risk lifecycle stops being manual:

This is the change your risk managers will feel most.

Before migration, a risk manager moved a risk through its lifecycle by hand. After migration, state is derived from the risk's latest advanced assessment:

| Assessment situation | Risk state |
| No assessment yet | Draft (or stays Monitor) |
| Assessment in progress, awaiting approval | Assess |
| Response tasks still open | Respond |
| Assessment complete | Monitor |

 

While an assessment sits in Awaiting approval, the risk still shows state Assess. Approval status lives on the assessment, not on the risk. If your team watches the risk record for a review step, retrain them to look at the assessment — this is precisely why no Review stage remains on the risk.

 

How the scoring changes in advanced risk:

Legacy Risk Management was fundamentally a monetary model: impact and likelihood on the risk were converted into currency, and Annualized Loss Expectancy = single-loss expectancy × annual rate of occurrence.

Advanced Risk is a factor-driven model: assessors answer factors defined by your methodology, each answer carries a score, and your configured formula aggregates them. Qualitative and quantitative become independent tracks you enable per assessment type.

| Capability | Risk Management (before) | Advanced Risk (now) |
| Qualitative scoring | Pick impact and likelihood on the risk; converted to currency behind the scenes. | Assessors answer methodology factors; each choice carries a score, aggregated by the assessment type's scoring logic, then mapped to a rating criterion |
| Annualized Loss Expectancy | Entered on the risk as SLE × ARO | Quantitative values entered per factor, combined by your quantitative formula defined in RAM |
| Control effect on score | Implicit — a failure-factor percentage interpolating between inherent and residual ALE | An explicit control assessment phase with its own effectiveness score feeding the residual phase; auditable instead of hidden in a formula |
| Statement-level scores | Statement defaults pushed down onto child risks | Risk results roll up into statement and entity results, recalculated continuously |
| Appetite and tolerance | Three form actions pushed tolerance values around manually ("Set tolerance from risk statement", "Set tolerance from downstream entities", "Inherit tolerance values from parent") | A full appetite framework with breach detection and downstream propagation. The action equivalent is "Copy qualitative appetite" — but it only appears once you've configured an appetite scale, which is why prerequisite 2 matters |

 

All the scoring figures land on the Risk form's new Assessment summary section: inherent, control effectiveness, residual and target scores alongside their ALE values, plus the primary methodology and chosen risk response.

One constraint to know: control assessments carry no ALE — control effectiveness is qualitative only.

 

What new in advanced risk:

1. Target scoring — a fourth phase alongside inherent, control and residual, with its own ALE
2. Risk Appetite and Tolerance as a framework, with breach detection and downstream propagation
3. Assessment Projects — campaign-style bulk assessment with grid and focus modes
4. Score rollup and aggregation up entity hierarchies, recalculated continuously
5. Inherent / control effectiveness / residual rating indicators on entities and risk statements
6. Risk-assessment task tracking, including overdue counts
7. Consolidated reporting views

 

Post-migration verification:

Work through this in your clone before production:

• Every entity class in use has a published, primary RAM
• Open a risk — does it show the Advanced Risk view, and does the Assess button appear?
• Run one assessment end to end: inherent → control → residual → target → approval → monitor
• Risk states look sensible; nothing unexpectedly stranded in Draft
• Appetite and tolerance render, and "Copy qualitative appetite" appears
• Entity and risk statement rating indicators populate
• Aggregation modules return data
• Any report, dashboard, filter or integration referencing legacy score fields or the Review state has been updated
• Your team knows to look at the assessment for approval status, not the risk
• Your risk team has worked a full cycle

 

Conclusion:

Advanced Risk turns risk scoring from a number someone typed in into a result you can defend. Rather than entering impact and likelihood on a risk, your assessors answer factors defined by a methodology you control — and every score traces back to a documented answer, an owner, and an approval.

That shift brings a few things worth having:

• A complete picture of a risk. Four phases — inherent, control effectiveness, residual and target — instead of one blended figure. You can finally show how much your controls are actually buying you.
• Quantitative and qualitative side by side. Monetary loss expectancy is still fully supported, now calculated from factors, and you choose per assessment type whether to score in ratings, currency, or both.
• Appetite that does something. Set appetite and tolerance and let the platform detect breaches and propagate them across your hierarchy.
• Assessment at scale. Assessment Projects run campaigns across many risks at once, and re-assessment is a first-class action from Monitor or Respond rather than a workaround.
• Scores that stay current. Results roll up entity and statement hierarchies continuously, so your reporting reflects assessments as they land.

Add a formal approval step on every assessment, plus automatic reassessment when a risk acceptance lapses, and you get a risk process that holds up when an auditor asks "how did you arrive at that?"